--- title: "Favro Integration" description: "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." url: https://flowrunner.ai/integrations/favro date_modified: 2026-09-04T14:21:17-07:00 --- # Favro [Project Management](https://flowrunner.ai/integrations/category/project-management-productivity) 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](https://favro.com/) · [Platform Documentation](https://favro.com/developer/) · Capability data verified 2026-08-18 1. On Card Event fires when a card is marked done on the delivery board 2. Get Card returns the card in full, with its tasklists, tags, and custom field values 3. List Cards run without the unique option reveals every widget the card is committed to 4. List Card Dependencies confirms nothing downstream is still waiting on it 5. Create Comment records the outcome on the card, where everyone following it is notified 6. 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](https://flowrunner.ai/concepts/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](https://flowrunner.ai/integrations/sentry) or a customer request logged in [Zendesk](https://flowrunner.ai/integrations/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](https://flowrunner.ai/integrations/slack), and the release notes draft appends to a document in [Google Docs](https://flowrunner.ai/integrations/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 6 - **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 5 - **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 5 - **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 5 - **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 6 - **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 6 - **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. ### Tags 5 - **List Tags** Retrieves the organization's tags. Tags are organization wide, so the same tag sits on cards across every board. - **Get Tag** Retrieves one tag. - **Create Tag** Creates a tag in the organization. Used to bring a classification an agent produces into the team's own vocabulary. - **Update Tag** Renames a tag or changes its color, and the change shows on every card carrying it. - **Delete Tag** Deletes a tag from the organization. It disappears from every card that carried it, which makes this a removal rather than a detach. ### Tasklists and Tasks 10 - **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 7 - **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 2 - **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 5 - **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 3 - **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 1 - **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. **Work at Favro?** This integration exposes Favro to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/favro. Site index: https://flowrunner.ai/llms.txt