SwiftKanban

SwiftKanban by Digité is the enterprise Kanban and Scrum board. Agents create, move and update cards, manage boards, lanes, sprints and releases, post comments and attachments, and act on behalf of other users where the activity log should show them.

93 actions Session available

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

A support desk escalates a defect that has to reach the delivery board

List Board Card Types resolves the internal card type the board uses for defects

List Cards By External Creator looks for a card already raised from the same source address

List Master Lists confirms the severity and class of service values this board will accept

Create Cards raises the card and lets the board's own entry policy decide where it lands

Add Card Comments posts the reporter, the source thread and the reproduction steps onto the card

The board owner decides whether the defect enters the current sprint or waits in the backlog

What This Integration Enables

SwiftKanban is the board for organizations that treat flow as something to be measured and governed, not just visualized. The board carries entry policies that decide where a new card lands, master lists that constrain what reasons a block or an abort may cite, business rules that fire when a card changes, and a movement log detailed enough to build a real cycle time report from. It runs hosted or on your own server. None of that is decoration: it is what makes the board defensible in an organization that has to answer for how work was prioritized.

FlowRunner agents work inside those rules rather than around them. They raise cards from external systems and let the entry policy place them, and they read the master lists before choosing a block reason. They move cards between queues using identifiers taken from the board configuration rather than from the labels people see, and they follow a card to its new identifier after a conversion or a transfer. Batches are first class here, and so is the fact that a batch can be half accepted. What an agent does not get to do is quietly destroy a record, because on this board every write is attributed to one connection identity, and that makes the human-in-the-loop step a matter of accountability rather than caution.

Without FlowRunner

Escalations retyped A defect is described once in the desk and again on the board, and the two drift apart

Cards lost when they change type Converting or transferring a card retires its identifier, and everything pointing at the old one goes quiet

Flow metrics assembled by hand Cycle time is worked out from a spreadsheet somebody maintains on the side

With FlowRunner

One escalation, one card The card is raised from the source with the reporter and thread attached, and matched so it is not raised twice

The reference follows the card A converted or transferred card is chased to its new identifier before anything reports on it

Movement history read directly Queue by queue movement is pulled from the board itself and summarized on a schedule

Use Case Scenarios

An escalation that arrives as a card the board will accept

A defect escalates from Zendesk or Freshdesk. Before writing anything the agent resolves the board's internal card type with List Board Card Types, because the value the API wants is the internal type rather than the display name on the board. List Cards By External Creator checks whether the same reporter already raised this, so a resent email does not become a second defect. Create Cards then raises the card without naming a lane, letting the board's entry policy place it where the team decided new work belongs. Add Card Attachments carries the log file across, Add Card Comments posts the reproduction steps, and Flag Cards raises a block with a reason taken from the account's own blocking reason list rather than invented.
Cycle time that nobody maintains a spreadsheet for

On a schedule the agent calls List Card Movements over the reporting window, which returns every queue a card passed through, and List Closed Cards for the work that left the board through archive, discard or abort. Cards that were converted or transferred during the window would otherwise vanish from the numbers, so the agent runs Get Card New Reference on each and follows them to their new identifiers. The assembled result lands in Google Sheets and a summary posts to Slack with the lanes where work is aging. The report is built from the board's own movement history rather than from anyone's recollection.
A release that closes when it is actually ready

SwiftKanban refuses to close a release while cards tagged to it are still open, which is a policy an agent should work with rather than fight. Ahead of the cutoff the agent calls List Release Cards, groups the still-open work by lane and by blocking flag, and reads the block reasons off the cards. Anything already delivered is confirmed against List Card Activity Log. Then it posts a readiness summary and stops. A person decides which open cards get untagged from the release with Untag Cards From Release and which ones hold the date. Only after that decision does the agent call Close Release.

Human-in-Loop Highlight

Delete Card and Delete Cards are the operations this connector gates, and the reason is specific to SwiftKanban. First, the board already ships three ways to take a card off it without destroying anything: Archive Cards, Discard Or Abort Cards and Move Cards To Backlog all keep the record, and archived cards come back through List Closed Cards. Deletion is the only one that removes the row that List Card Movements and every cycle time number were built from. Second, a card here is addressed by its type joined to its identifier, so a batch delete is a list of pairs, and a pairing that is subtly wrong removes a different card without complaining. Third, and worst, the activity log attributes every write to the login the connection uses, which for an agent is one dedicated integration user. The board's own audit trail cannot tell you which person wanted this. So the cleanup agent assembles the case and asks in the delivery channel: "17 cards on the Platform board have had no movement in 90 days. 14 are stale duplicates of cards already closed. 3 carry attachments and comment threads. Archive all 17, delete only the 14 duplicates, or leave them?" The named answer becomes the record, because the board will not keep one.

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

93 actions

Boards

List Boards Returns the boards the connection can see. SwiftKanban calls a board a project internally, so each row carries both names and the board identifier is what every other operation wants.
Get Board Returns one board.
Get Board Configuration Returns the board's lanes with their queues and subqueues. This is where the queue identifiers a move needs come from.
List Board Lanes Returns the board's smart lanes, the horizontal swimlanes a card sits in.
List Lane Cards Returns one lane's queues together with the cards standing in each.
List Board Policies Returns the board's policies, which decide where a new card lands and what a lane will accept.
List Board Dynamic Lists Returns every dynamic data list configured on the board along with the items each allows. These are the board's own dropdown fields.
List Business Rules Returns the board's business rules, the automations SwiftKanban runs when a card changes.

Cards

List Cards Returns the cards on a board, narrowed by the vendor's own filter dialect.
Get Card Returns one card. A card is addressed by its type and its identifier together, and the identifier may be the numeric id or the card number.
List Closed Cards Returns cards that have left the board through archive, discard or abort. The one paged listing in this API.
List Cards Created Since Returns cards of one type created on or after a moment, which is the cheapest way to poll a board for new work.
List Card Movements Returns the movement log for a board over a window, recording every queue a card passed through. The source a cycle time report is built from.
List Cards By External Creator Returns cards across every board raised by an outside address, which is how work pushed in from another system is found again.
Get Card New Reference Returns where a card went after a conversion or a transfer. Both operations retire the old identifier, so this is what follows the card.
Create Cards Adds one card or a batch of them. Where a card lands is decided by the board's entry policy unless a lane and queue are named.
Update Cards Changes one card or a batch of them. Only the attributes supplied are touched.
Delete Card Deletes one card outright rather than closing it. Gated on this page, because the board offers non-destructive alternatives that keep the record.
Delete Cards Deletes several cards at once, each addressed by its type joined to its identifier. The same gate applies, and more so, because a wrong pairing removes a different card silently.
Archive Cards Archives cards, taking them off the board while keeping the record. The reversible way to clear a board.
Discard Or Abort Cards Closes cards as discarded or aborted with a reason. Which of the two it becomes is decided by where the card stands, and the reason has to come from the account's abort reason list.
Convert Cards Changes cards from one type to another, for example a defect into a user story. Conversion issues a new identifier, so the reference has to be chased afterwards.
Flag Cards Raises a block or a risk flag on cards with a reason and a note, taken from the account's blocking reason list.
Unflag Cards Clears a block or risk flag. The kind of flag has to match the one raised, so clearing a block on a card carrying a risk does nothing.
Move Cards To Backlog Sends cards back to the backlog, off the board, without destroying anything.
Move Cards To Ready Brings cards from the backlog onto the board's ready queue.
Move Cards On Board Moves cards to another lane and queue on the same board, using identifiers read from the board configuration rather than the names shown on the board.
Transfer Cards Moves cards to a different board. Transfer issues a new identifier on the destination, so a workflow holding the old one has to follow it.

Releases

List Releases Returns the releases defined on a board.
Get Release Returns one release.
List Release Cards Returns the cards tagged to a release. The readiness check before any close.
Create Releases Adds one release to a board or a batch of them.
Update Releases Changes one release or a batch of them, touching only the attributes supplied.
Close Release Closes a release. SwiftKanban refuses while cards tagged to it are still open, which is why a close is always preceded by a read.
Delete Release Deletes a release from a board. Cards tagged to it are untagged rather than deleted.
Tag Cards To Release Attaches cards to a release. Each card carries its own board identifier, because a release can gather cards from more than one board.
Untag Cards From Release Removes cards from a release, which is how work is pushed to the next one without deleting it.

Sprints

List Sprints Returns the sprints on a board. SwiftKanban calls a sprint an iteration internally.
Get Sprint Returns one sprint.
List Release Sprints Returns the sprints that belong to a release.
List Sprint Cards Returns the cards tagged to a sprint.
Create Sprints Adds one sprint to a board or a batch of them. A sprint is placed in a release by name rather than by identifier.
Update Sprints Changes one sprint or a batch of them, touching only the attributes supplied.
Close Sprint Closes a sprint.
Delete Sprint Deletes a sprint from a board. Cards tagged to it are untagged rather than deleted.
Tag Cards To Sprint Attaches cards to a sprint, which is how a planning decision made elsewhere reaches the board.
Untag Cards From Sprint Removes cards from a sprint.

To-Dos

List Card To-Dos Returns the to-dos on a card, which are the checklist items inside it.
Get Card To-Do Returns one to-do from a card.
List To-Dos Created Since Returns to-dos created on or after a moment, across the cards of one type on a board.
Create Card To-Dos Adds one to-do to a card or a batch of them. Leaving the owner empty records the literal word unassigned rather than nobody.
Update Card To-Dos Changes one to-do on a card or a batch of them.
Delete Card To-Do Deletes one to-do from a card.
Delete Card To-Dos Deletes several to-dos from a card at once.

Comments

List Card Comments Returns the comments on one card, threaded through each comment's reply reference.
List Comments Across Cards Returns comments from several cards at once, narrowed by author and by date. It returns only the latest few per card unless told otherwise.
List Item Comments Returns the comments on something that is not a card, such as a person profile.
Add Card Comments Adds one comment to a card or a batch of them. An external identifier lets another system recognize its own comment on the way back.
Reply To Card Comment Adds a reply beneath an existing comment on a card, which keeps a conversation grouped.
Update Card Comments Changes the text of an existing comment on a card.

Attachments

List Card Attachments Returns the attachments on a card. Including the bytes returns every file encoded in the same answer, which on a card with several large files is a very big response.
Get Card Attachment Returns one attachment together with its bytes.
List Item Attachments Returns the attachments on something that is not a card.
Get Attachment Size Limit Returns the largest single attachment the account accepts, which is worth reading before an upload because an oversized file is refused only after the whole body has been sent.
Add Card Attachments Adds a file to a card. The file travels encoded inside the request body, so a workflow holding a URL fetches and encodes the bytes first.
Delete Card Attachment Deletes one attachment from a card.
Delete Card Attachments Deletes several attachments from a card at once.

Relations

List Card Relations Returns everything one card is linked to. The answer arrives in two lists, and which side a link sits on is what tells a parent from a child.
List Board Relations Returns every relation among a board's cards, optionally narrowed to particular cards, types or kinds of link.
Add Card Relations Links a card to others. Direction is chosen by which list the link goes in, so getting it backwards builds a valid but inverted hierarchy.
Delete Card Relations Removes links between a card and others. A link has to be named on the same side it was created on.

Users and Teams

List Users Returns the account's users. The filter dialect here is not the one the card operations use.
Get User Returns one user.
Get Authenticated User Returns the user the configured credentials belong to. The cheapest way to check that a connection works.
Create Users Adds one user to the account or a batch of them. This consumes a license per user, and the login identifier cannot be changed afterwards.
Delete User Deletes one user from the account.
Delete Users Deletes several users at once. This connector refuses an empty identifier list rather than accepting it, because what an empty list would mean is not documented.
List Teams Returns the account's teams.
List Board Team Members Returns the people on one board and the role each holds there.
List Team Members Across Boards Returns the membership of every board at once, board by board.
Invite Team Members Adds an existing account user to a board with a role. Somebody with no account yet has to be created first.
Get Account Returns the account this connection belongs to, with its organization details.

Board Metadata

List Board Card Types Returns the card types a board uses, with the internal code, color and display name of each. Where the card type every other operation asks for comes from.
List Card Type Relations Returns which card types may sit above or below another in a parent and child link, which avoids building a link the board will not keep.
Get Item Metadata Returns the attribute definitions for a card type or another item type. The authority on what a field is named and what it accepts.
List Master Lists Returns the account's master lists, which hold the allowed values behind fields such as class of service, blocking reason and abort reason. A value that is not on the list is refused.
Get Master List Returns one master list.
List Relation Types Returns the kinds of link cards may have, with the subtypes of each.
List Dynamic List Values Returns the values a board's dynamic dropdown field allows.

Activity Log

List Card Activity Log Returns what changed on particular cards and when. Unlike the other listings this one requires the cards to be named.
List Card To-Do Activity Log Returns what changed on the to-dos inside one card.
List To-Do Activity Log Returns what changed on one to-do.
List Relation Activity Log Returns the links created and removed across the account since a moment. Account wide rather than per board, which makes it the way to notice a hierarchy changing.

Frequently Asked Questions

What can FlowRunner do with SwiftKanban?

FlowRunner agents can run List Boards, Get Board, and Get Board Configuration in SwiftKanban, plus 90 more actions.

Does connecting SwiftKanban to FlowRunner require OAuth?

No. SwiftKanban connects to FlowRunner with session-based authentication, no OAuth flow required.

Can SwiftKanban trigger a FlowRunner workflow automatically?

SwiftKanban doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with SwiftKanban

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us