Skip to content

Enterprise Kanban

KanbanPlugin turns canonical grid.source rows into workflow cards without creating a second data model. Configured workflow columns become RevoGrid columns and optional swimlanes expand into native card rows. Every workflow cell contains at most one card, so RevoGrid owns both horizontal and vertical virtualization.

One source, multiple views

Keep cards in grid.source. Set grid.kanban to show the board and set it to false to restore the latest cards and table columns.

Provider-backed

RevoGrid providers own projected data, columns, dimensions, focus, viewport state, and plugin dependencies.

Workflow interaction

Reorder cards, move across columns or lanes, drag a multi-selection, validate transitions, and enforce WIP limits.

Product-owned content

Replace card, header, lane, empty-state, and drag-preview content while the managed shell preserves interaction and accessibility.

import { KanbanPlugin, type KanbanConfig } from '@revolist/revogrid-enterprise';
const kanban: KanbanConfig = {
columns: [
{ prop: 'todo', name: 'To do' },
{ prop: 'doing', name: 'In progress', wipLimit: 3 },
{ prop: 'done', name: 'Done' },
],
card: { titleField: 'title', descriptionField: 'description' },
};
grid.plugins = [KanbanPlugin];
grid.kanban = kanban;
grid.kanbanCardEditorDialog = {};
grid.source = [
{ id: 'card-1', title: 'First card', status: 'todo', order: 1000 },
];

The default fields are id, status, and order. Configure idField, columnField, or orderField when your application uses other names.

columns is optional so Kanban can be enabled before workflow metadata or data loads. An empty configuration and empty source render a stable empty board. If cards arrive before columns, they remain visible in the managed Unmapped column until the workflow configuration is supplied.

canonical grid.source cards
+ KanbanConfig
validated card and bucket indexes
RevoGrid columns + expandable swimlane card rows

Your application owns the card records and persistence. Kanban owns projection, interaction, validation, and local provider updates. Move events describe the exact changes to persist.

  1. Define stable card IDs and explicit workflow columns.
  2. Add swimlanes, WIP limits, and card rules if the workflow needs capacity or policy controls.
  3. Configure the packaged card editor or a replacement UI.
  4. Connect events and public methods to application persistence.
  5. Add custom card content and translations.
  6. Verify accessibility and performance with production-sized data.