Features · Boards
Boards that stay live
Drag-and-drop kanban with updates streamed to every open browser.
Every project gets a kanban board out of the box — one column per workflow status, no setup. When your team needs more, add boards of your own: map columns to statuses, set WIP limits, split rows into swimlanes, and scope each board with a TQL query. Changes land on every open board live, over a per-project event stream.
What you get
- Drag, drop, done — Dragging a card to another column transitions the ticket — the UI updates instantly, then rolls back with an error if the workflow forbids that transition.
- Live for everyone — Ticket edits, quick-adds, sprint changes and automation runs publish an event after commit; every browser watching the project refreshes over Server-Sent Events, delivered across backend nodes via Postgres NOTIFY/LISTEN.
- Swimlanes four ways — Split the board into rows by assignee, type, priority, or epic; unassigned and no-epic lanes sort to the bottom.
- WIP limits per column — Each column can carry a work-in-progress limit; the header shows the count against it and flags the column when it is exceeded.
- Scoped by query — Give a board a TQL scope and it shows only matching tickets — leave it blank and it shows the whole project.
- Cards your way — Choose which chips cards show — labels, type, assignee, priority, due date, estimate — with overdue dates flagged, plus per-column quick-add and inline assignee and priority editing right on the card.
See it
Columns map statuses, not the other way round
A column is a named bucket over one or more workflow statuses, so a single "In review" column can gather several review states. Dropping a card on a multi-status column transitions the ticket to the column's primary status, and the column header lists every status it covers. Column edits validate that each status belongs to the project's workflow, and board configuration changes are recorded in the audit log.
Live updates that survive a cluster
Board mutations publish an event only after the database commit, so no browser ever sees a change that later rolled back. Events travel between backend nodes over Postgres NOTIFY/LISTEN, which means your board updates even when the change was handled by a different node behind the load balancer. If the connection drops, the browser reconnects on its own.
Boards are views, not silos
Board tables store configuration only — columns, status mappings, WIP limits, swimlane choice, scope query. Ticket data always comes from the ticket APIs, so the default board appears on every project with zero seeded rows, and deleting a board never touches a ticket. Viewing a board requires project membership; creating, configuring, or deleting one requires a project admin.
In practice
Board scope (TQL): priority = HIGHSee Iskue on your own screen
A demo takes half an hour. A pilot runs on your servers, with your data, from day one.