Favro

Favro is collaborative planning where collections hold boards and backlogs, and columns hold cards. Agents create and move cards, set custom field values on cards, manage collections and widgets, and react to card changes as they land.

1 trigger 65 actions Basic auth available

Favro website Platform Documentation Capability data verified 2026-08-18

On Card Event fires when a card is marked done on the delivery board

Get Card returns the card in full, with its tasklists, tags, and custom field values

List Cards run without the unique option reveals every widget the card is committed to

List Card Dependencies confirms nothing downstream is still waiting on it

Create Comment records the outcome on the card, where everyone following it is notified

The board owner picks the cleanup scope, because one delete can clear the card from every board it lives on

What This Integration Enables

Favro is built on a claim most planning tools do not make: one piece of work can legitimately live on several boards at once, and it should be the same card in each place rather than a copy someone keeps in step. That is why a card can be committed to multiple widgets, why tags are defined once for the whole organization, and why the operations that remove things take a scope. It is a good model for teams whose roadmap, backlog, and delivery board are three views of one plan instead of three plans.

FlowRunner agents work that structure directly. They create cards from incoming work, move or commit them between widgets, maintain tasklists and dependencies, read and write the organization's custom fields, post comments that reach every follower of a card, and manage the collections, columns, and groups that decide who sees what. The On Card Event trigger closes the loop, so a card moving on a board can start a flow rather than waiting for someone to notice. The one thing agents do not decide here is how far a removal reaches, which is where this connector's human-in-the-loop gate sits.

Without FlowRunner

The same work tracked twice A roadmap item and its sprint card drift apart because they are separate records maintained by hand

Cleanup avoided out of caution Nobody archives anything, because it is not obvious what a delete will take with it

Board state read by eye Knowing what moved this week means opening every board and scrolling

With FlowRunner

One card, several contexts The card committed to the roadmap and the sprint board is the same card, updated once

Cleanup with the blast radius shown Every widget a card touches is listed before anyone chooses how far the delete reaches

Board state read as events Card and comment changes arrive as they happen and drive the next step

Use Case Scenarios

Incoming work becomes a card on the right board

A bug reported in Sentry or a customer request logged in Zendesk reaches the agent. It resolves the target widget with List Widgets and the right column with List Columns, then calls Create Card with the widget named explicitly, since a card created without one lands in the connected user's private list where nobody else will ever see it. It resolves the organization's tag vocabulary with List Tags, attaches the ones that apply, and adds a tasklist of the reproduction steps with Create Tasklist. The reporter's context arrives with the card instead of being retyped from a thread.
A release board that assembles itself

When a card moves into a done column, On Card Event fires. The agent reads the card, checks its tasklists are complete and its required custom fields are set, then calls Update Card to commit it to the release board so the same card now appears in both planning contexts. Create Link style sequencing is handled with Add Card Dependencies where one item genuinely blocks another. A digest of what joined the release posts to Slack, and the release notes draft appends to a document in Google Docs. Nobody maintains a second copy of the release scope, because there is not one.
Access that follows the project rather than trailing it

A new client engagement starts. The agent calls Create Collection for the engagement, Create Widget for its board and backlog, and Create Column to lay out the workflow stages the team actually uses. It then shares the collection with the right people through a group rather than one by one, using List Groups and Update Group so access is granted and revoked in one place. When the engagement closes, Update Widget archives the boards, and the collection's sharing is tightened rather than left open. Sharing settings are checked explicitly, because a collection set to public sharing is readable by anyone who has the address.

Human-in-Loop Highlight

In most tools, a delete has a fixed blast radius. In Favro it is a parameter. Delete Card removes the card from this widget, or, with the everywhere option enabled, from every widget it was ever committed to. Delete Widget behaves the same way in reverse: name a collection and only that instance goes, leave it empty and the widget is removed from every collection it sits in. A card's own record does not tell you how much is at stake, which means an agent cleaning up finished work is one boolean away from clearing a roadmap.

So the cleanup agent never chooses the scope. It calls List Cards without the unique option, which returns the card once per widget, and reports exactly what it found: "Card 'Migrate billing webhooks' is committed to 4 widgets: Q3 Roadmap, Platform Sprint 18, Billing Backlog, and Support Escalations. Removing it here clears it from Platform Sprint 18 only. Everywhere clears it from all four. Which?" The board owner answers, and the agent runs the one option it was given. The same gate covers Delete Tag, which is not a detach but a removal from every card in the organization that carries it, and Set Card Dependencies, which drops any dependency not named in the call.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

65 actions

Users and Organizations

List Users Retrieves the people in the organization. Used to resolve an owner or assignee before a write.
Get User Retrieves one person. Rate limited per user rather than per organization, so flows fetch in bulk where they can.
List Organizations Retrieves the organizations the credentials can reach. Run first, since every other operation needs an organization identifier.
Get Organization Retrieves one organization including its members and their roles. Used to audit who holds what access.
Create Organization Creates an organization and optionally invites people into it. Everyone named is emailed an invitation, which makes this a reviewed operation rather than a routine one.
Update Organization Renames an organization, changes what people can do in it, or removes them from it. A member entry carrying a delete flag removes that person, so membership sweeps are built carefully.

Collections

List Collections Retrieves the collections in the organization. A collection is the container widgets live in.
Get Collection Retrieves one collection including who it is shared with. Used in access reviews.
Create Collection Creates a collection. Public sharing makes it readable by anyone on the internet who has the address, so provisioning flows set sharing explicitly rather than accepting a default.
Update Collection Changes a collection's name, appearance, sharing, or membership. The operation that tightens access when an engagement closes.
Delete Collection Deletes a collection. The widgets inside are not deleted, they stop being reachable through this collection.

Widgets

List Widgets Retrieves the widgets in the organization. A widget is a board or a backlog, and it is the thing cards live on.
Get Widget Retrieves one widget with its configuration.
Create Widget Creates a board or a backlog in a collection. Boards default to a Kanban view with columns, backlogs to a card list.
Update Widget Changes a widget's name, color, or roles, or archives it. Archiving names the collection as well, because a widget can sit in more than one.
Delete Widget Deletes a widget. Naming a collection removes only that instance; leaving it empty removes the widget from every collection it sits in, which is why this is gated.

Columns

List Columns Retrieves the columns of a board. Used to resolve a stage by name before moving a card.
Get Column Retrieves one column.
Create Column Adds a column to a board, at the end by default.
Update Column Renames a column or moves it along the board.
Delete Column Deletes a column from its board, and anything sitting in it goes too.

Cards

List Cards Retrieves cards narrowed by widget, column, collection, or identifier. Run without the unique option, it returns a card once per widget, which is how a flow discovers everywhere a card lives.
Get Card Retrieves one card in full. The read behind any decision about that card.
Create Card Creates a card. The widget is always named, because a card created without one lands in the connected user's private list rather than on a board.
Update Card Changes a card, including moving it. Naming a widget moves or commits the card there, and the drag mode decides which, so a sync flow states its intent rather than relying on a default.
Delete Card Deletes a card from this widget, or from every widget it was committed to when the everywhere option is enabled. The operation this page's human gate exists for.
List Card Activities Retrieves what has happened to a card, optionally within a window of time. Used to reconstruct how an item reached its current state.

Card Dependencies

List Card Dependencies Retrieves the cards one card depends on and the cards that depend on it. Read before anything is closed or removed.
Add Card Dependencies Adds dependencies to a card, leaving existing ones in place. The additive write, and the safe default for automation.
Set Card Dependencies Replaces a card's dependencies with the ones given. Anything not in the list is removed, which is what separates it from the additive operation.
Update Card Dependency Changes whether one dependency comes before or after the card it is attached to.
Delete Card Dependency Removes one dependency from a card.
Delete All Card Dependencies Removes every dependency from a card at once. Used in reviewed teardown, not in routine cleanup.

Tasklists and Tasks

List Tasklists Retrieves the tasklists on a card. A card can carry several, each with its own tasks.
Get Tasklist Retrieves one tasklist.
Create Tasklist Adds a tasklist to a card, optionally with its tasks in the same call. Used to turn a procedure into a checklist the assignee can work down.
Update Tasklist Renames a tasklist or moves it up and down the card.
Delete Tasklist Deletes a tasklist from its card, and every task in it goes too.
List Tasks Retrieves the tasks on a card, optionally narrowed to one tasklist. Used to check completeness before a card advances.
Get Task Retrieves one task.
Create Task Adds a task to a tasklist.
Update Task Renames a task, moves it, or ticks it off and back on again.
Delete Task Deletes a task from its tasklist.

Comments and Files

List Comments Retrieves the comments on a card. Used to summarize a discussion into a status update.
Get Comment Retrieves one comment.
Create Comment Posts a comment on a card. Everyone following the card is notified, which makes this the operation that reaches people.
Update Comment Rewrites a comment or strips attachments from it. Pointed only at comments the automation itself wrote, since it replaces somebody's words.
Delete Comment Deletes a comment from its card.
Attach File To Card Uploads a file from a public address and attaches it to a card. Used to land a spec, a design export, or a report where the work is.
Attach File To Comment Uploads a file from a public address and attaches it to a comment.

Custom Fields

List Custom Fields Retrieves the custom fields defined in the organization, which is how the identifiers on a card translate into names a person recognizes.
Get Custom Field Retrieves one custom field, including the options it offers if it is a list. Read before writing a value, so the write uses an option that exists.

Groups

List Groups Retrieves the groups in the organization. A group is a named set of people that can be shared onto things all at once.
Get Group Retrieves one group and who is in it.
Create Group Creates a group of people in the organization. Used so access is granted to a role rather than to a list of individuals.
Update Group Renames a group or changes who is in it. A member entry carrying a delete flag removes that person.
Delete Group Deletes a group. The people in it keep their own access, only the grouping goes away.

Webhooks

List Webhooks Retrieves the outgoing webhooks configured in the organization, optionally narrowed to one widget. The response includes each webhook's signing secret, so flows handle it as a credential.
Create Webhook Creates an outgoing webhook on a widget, for delivering events somewhere other than FlowRunner. A flow that wants the events itself uses the On Card Event trigger, which manages its own webhook.
Delete Webhook Deletes an outgoing webhook so Favro stops posting to it.

Triggers

1 triggers

Event Triggers

On Card Event Fires when a card or a comment changes on the chosen widget. Favro subscribes with one vocabulary and delivers another, so the connector reports a single normalized event name such as a card created or a comment created. This is what turns a board move into the start of a flow rather than something a person has to notice.

Frequently Asked Questions

What can FlowRunner do with Favro?

FlowRunner agents can run List Users, Get User, and List Organizations in Favro, plus 62 more actions.

Does connecting Favro to FlowRunner require OAuth?

No. Favro connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.

Can Favro trigger a FlowRunner workflow automatically?

Yes. Favro supports 1 trigger that can start a FlowRunner workflow automatically.

Start building with Favro

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us