Boards (Kanban)
The same records as the grid, drawn as columns by status. Drag, multi-select, swimlane, configure what shows on a card. Sprint boards mix plans and bugs in the same lanes.
The board is the second way you look at the same records. The grid groups them as rows, the board groups them by status. A drag moves a card from one status to another and updates the underlying record in one motion. There is no separate "board data," no parallel state to keep in sync. The board reads from the same store the grid reads from, the same store the agent reads from when it works.
Three boards are wired today on a shared Kanban primitive: the initiatives board (status columns on the initiative workflow), the plans board (status columns on the plan workflow), and the sprint backlog board, which is the most interesting of the three because it carries plans and bugs together in the same columns. Bugs do not have a standalone board today; they show up on the sprint board and live in the grid for everything else.
A column for each status, a card for each record
Open an initiatives board and the columns are the statuses on the initiative workflow, in the order the workflow defines them. The cards in each column are the initiatives currently in that status. Drag a card across columns and the record's status changes. The audit log gets the event, the version history gets the snapshot, and every grid, board, and roadmap that cares about the record updates within a beat.
What a card shows is configured the same way grid columns are: through the entity's workflow. An admin picks the card fields from a per-entity catalog (the title is always there; everything else is selectable) and saves them. From that moment forward, every initiatives card across the workspace shows the same set of fields. Owner, due date, project, plan count, anything from the catalog. The board layer just renders what the workflow says to render.
Whether a column can accept a new card from its quick-add menu is also a workflow decision. The "creatable" flag on a status controls whether the column header offers an "Add initiative" action. A status meant to be reached only through a transition (a review column, a verified column) can be configured to refuse direct creation, while the everyday columns still let you start new work from the board.
Dragging a single card
Cards drag with native-feeling weight. Pick one up and a placeholder slot opens at the position the card will land if you drop now; the layout reflows around it, the source card stays visible at reduced opacity so you can see where it came from, the destination column shows exactly where the card will sit.
The drag respects the grid's reading order, so a reorder within a column lands at the slot under your cursor, not at the bottom. Drag across columns and the source's status updates the moment you drop. Drop on the same column at the same position and the platform recognizes the no-op; no audit row, no SSE event, no version snapshot for a move that did not happen.
Dragging several at once
Cards drag in groups too. Click one card, hold cmd or ctrl and click a second, click a third, and they all move together. A small stacked preview at the cursor shows the count so a multi-select move never feels like a single-select gone wrong.
Under the hood the platform fans the move out into one operation per card, so the audit log shows three discrete updates rather than one mystery batch. From your point of view, it was a single drag.
Multi-select drag is wired on the initiatives board and the plans board today. The sprint backlog runs single-card drags only at the moment because the cross-type rules (plan-to-bug and back) are tighter; multi-drag there is a planned follow-up.
A drag inside a column reorders the work, it does not just refresh a status. Drop a card between two others and it takes the position between them, and the next person who opens the board sees the same order you do. The board uses the same neighbor-based reorder the sprint backlog does, so a single drag captures the move you actually wanted to make.
Swimlanes split a column without splitting the workflow
Some boards want a second dimension. A sprint board reads better when the rows are owners, so each engineer can see their own slice of the work in flight. A backlog reads better when the rows are projects, so you can see what is in motion per project without filtering down. The board supports this with swimlanes.
Swimlanes group cards within a column by a second field (an owner, a project, a label). Each lane gets a header on the left with a count and a chevron to collapse it; collapsed lanes vanish from the column entirely until you expand them again. The column totals at the top of the board roll up across lanes, so the count you read on the In Progress column header is the true total even when half the lanes are collapsed.
Not every consumer wires swimlanes the same way. The initiatives and plans boards run as a single default lane today, since the primary axis for those is status. The sprint board groups by assignee, which matches how people actually triage the work in flight.
A column can carry a WIP limit, in which case the header shows the count in a warning color when the column exceeds the limit. The platform does not block the drop. The decision to enforce the limit is a team-level convention, not a hard product rule; the indicator is there to make the conversation easy to have.
Mixed-entity columns on a sprint board
The sprint backlog board is the place where the model gets interesting, because a sprint holds two kinds of record at once: plans and bugs. The columns are the same four statuses (Todo, In Progress, Blocked, Done) and a card can be either type, with a small badge that tells you which.
The shape of how those two record types share columns took deliberate work. Plans have a "blocked" status; bugs do not. So when a bug card lands in the Blocked column, the board recognizes that the move does not map to a real status on a bug, surfaces a clear error rather than writing a phantom value, and the bug stays where it was. The other three columns map cleanly between the two types, so the sprint board stays useful for the kind of work that mixes engineering and defect cleanup in the same iteration.
Reordering within a sprint column is the same operation across both types. The sprint stores a single ordered list of items where a plan and a bug can sit next to each other; a drag between them updates one record and lands the new position in a single round trip. Cross-lane moves work too when the lane is assignee, with the destination assignee picked up from the lane you drop into.
Live updates
The board reflects changes made elsewhere in the workspace as they happen. Move a plan from a chat with the agent, change a status from the grid, accept a Flow checkpoint that advances a plan to In Progress: the card on the board updates within the round trip of the SSE message that announces the change.
Your own in-flight drag is paused while a record is being written, so an SSE echo of your own move does not snap the card around mid-gesture. The cards you are not touching update around you; the one in your hand stays where you put it until you let go.
What you can do without a drag
A drag is the obvious move on a board, but a board is not a drag-only surface. Each card carries a kebab menu with the operations that apply to that record. Move the card to the top of the column without dragging, send the work to the background to run on its own, open the record in a new tab, delete it. The same operations a drag can do are reachable through the menu, which is the right shape for keyboard users and for the moments when you know exactly where the card should go.
Clicking the body of a card opens the record in Quick View, which lifts the full detail into a modal over the board without taking you out of the column you were reading. Close the modal and you are back on the same card, in the same lane, with your scroll preserved.
Multi-select-and-drag is the third move on top of those. Click a card, hold cmd or ctrl, click a second, click a third, drag them together. Use it when you want to clear out a column without scrolling back and forth between rows.
Accessibility comes with the board
The board announces every drag through a screen-reader live region, so the move you make with a mouse reads correctly out loud. A multi-select drag of three cards announces as "3 items moved to In Progress," not as a silent visual change. The same announcement covers reorders within a column and cross-column moves. A keyboard user, a screen-reader user, and a mouse user get the same feedback about the same change.
The same records, drawn differently
The board is the second view of the same records. The grid is the first. The roadmap is the third. Pick the one that fits the moment; the records, the audit, the agent's writes, all flow through the same store either way. A status changed on the board is the same status changed in the grid, the same status the agent sees the next time it pulls a plan into context.