Kanban Boards

A board is where you and your agents share a view of what's in flight. Any Record from any Page can appear as a card — assign it to whoever's handling it, drag it between columns as it moves.

Boards vs. Pages

These are separate concepts that work together. A Page holds the raw data (fields and submissions). A Board is a workflow view — it shows records as cards in columns that represent stages like "New", "In Progress", and "Done".

One record can appear on multiple boards simultaneously. This lets you cross-reference work: for example, the same bug report could appear on a "Customer Issues" board and a "Sprint 12" board at the same time.

Boards are for your team, not your submitters. Only signed-in internal users (and external users on the Team plan, for the pages they're granted access to) can ever see a board. Someone who fills out a public page has no way to see it land on a board, which column it's in, or what happens to it next — they only get the page's success message. If a submitter needs to track their request, use a post-submit webhook to email a confirmation or reference number; there's no built-in "check your status" page for external users. Design your board/page pair with this in mind — it's the same model as a support-ticket inbox: staff work the queue, requesters don't watch it happen.

Creating a board

Click Boards in the sidebar, then New Board. Give it a name that describes the workflow (e.g., "Support Queue", "Content Pipeline", "Sprint 14"). New boards start with three columns: To Do, In Progress, and Done. You can rename a column by clicking its title, recolor it from the column menu, reorder columns by dragging their headers, and add more at any time.

Board structure is an Admin/Owner action. Creating a board and any change to its columns — add, rename, recolor, reorder, delete — requires the Admin or Owner role. Editors work the board day to day (move cards, add existing records, remove cards) but don't restructure it. See Access levels for the full breakdown.

Adding records to a board

There are two ways to add records:

Card previews show the record's title plus any fields marked Show on board card in the page builder.

Automatically add new submissions to a board: In the page's Kanban tab, set a Default Board. Every new record — whether submitted via the public page, the API, or in the app — is placed on that board automatically. You can also pick a Default Column; otherwise cards land in the board's first column.

Removing a card

Removing a card from a board only unlinks it — the record and its data are untouched, it just no longer has a card on that board. Any Editor, Admin, or Owner can remove a card.

If a card was removed by mistake, open the board and look for the Unassigned (N) button in the header — it lists every record for that board with no card, and lets you put one back in a column of your choice. It only appears when there's something to restore.

Columns

Columns represent stages in your workflow. Each column has a name and an optional color indicator. Admins and owners can:

Editors don't see these controls — column structure is Admin/Owner-only. Editors can still add an existing record to a column from its menu (Add Existing Record), same as anyone.

Card detail and add-ons

Clicking a card opens the record detail panel — the same view you get from the page's record list. From here you can:

FeatureDescription
Field valuesView and edit the record's submitted field data
CommentsAdd internal notes visible to your team only. Comments support plain text and code blocks.
File attachmentsAttach files directly to the record — separate from any file fields in the original submission
Audit logFull history of every field change, comment, column move, and file action with timestamps and author
Board columnChange which column this card appears in without leaving the detail panel

Drag and drop

Drag any card to a different column to update its status. The change is saved and recorded in the audit log immediately. If the target column has a WIP limit and is already full, the move is rejected.

Assigning a card — to a person or an agent

Every record has an assigned_to field. It's a name, not a type — so it holds a teammate's name or an API key's name equally well. There's no separate "assign to a bot" mechanism; it's the same field, the same dropdown, the same card.

Set it however you're already working: drag-and-drop it in a card's detail panel, set it on submission, or let an agent claim it. To see who's assignable in your org — people and active API keys both — call list_assignees (or check the assignee dropdown in the app).

How an agent checks its own queue

An agent connected over MCP or the API can call list_records with assigned_to: "me" and get back exactly the cards that are its responsibility — nothing else on the board. That's the whole mechanism: no polling everything and filtering client-side, no separate task queue to keep in sync. It works the cards, then moves them forward the same way a person would — updating status, commenting, dragging (via the API) to the next column.

Other common patterns:

See AI Agents & MCP for how to connect an agent and give it a name it can be assigned under.

Best practice: Keep column names short and action-oriented ("Review", not "Waiting for Review"). Agents read column names to understand state — clear names lead to better agent behavior.

Board limits by plan

Boards are unlimited on every plan, including Free. Cards per board are unlimited on all plans too. See Plans & Limits for the full breakdown.