Features · Workflow
A workflow engine, not a status list
Per-project statuses and transition rules, validated on every move.
Every project gets its own workflow: named statuses, the transitions between them, and the rules that guard each move. Statuses are first-class records in the database — not a hard-coded enum — so your team can rename, reorder, add and retire them without touching code. The engine validates every status change and tells the client exactly which moves are open right now.
What you get
- Per-project statuses — define, rename, reorder and delete statuses in Settings → Workflow, in a table or a graphical diagram view with draggable status nodes.
- Templates seed workflows — the moment a project is created, its template (Scrum, Kanban, Bug tracking or Portfolio) seeds a working set of statuses and transitions — no setup step.
- Validated transitions — a status change only commits if it matches a defined transition in that ticket's workflow; anything else is rejected with a clear message.
- Allowed-transitions API — one call returns only the statuses the current user can move this ticket to, with each transition's conditions already evaluated — so the UI never offers a move the workflow's conditions forbid.
- Rules on transitions — attach conditions, validators and post-functions to any transition to gate who can move a ticket, what must be filled in first, and what happens after.
- Status as data — ticket status is a foreign key to a workflow_status row, so renames propagate everywhere, and guarded deletes protect the initial status and any status tickets currently occupy.
See it
…or five statuses, or nine — with exactly the transitions your team allows.
Three kinds of rule on every transition
A condition gates whether the transition is offered at all — by permission, project role, a field predicate, or every requested approval being granted. A validator is a must-pass check before the change commits, such as a required field, and fails with the message you wrote. A post-function runs after the status change and reuses the automation action vocabulary: assign, set priority, add a label, add a comment. A transition with no rules behaves exactly as it always did — always offered, always valid.
Status is a foreign key, not an enum
Each ticket's status references a workflow_status row in the database rather than a value baked into the code. Rename a status and every board, report and ticket reflects it immediately; change history stays intact. Deletes are guarded twice: the initial status cannot be removed, and neither can any status that tickets are currently in. Every workflow change is recorded in the configuration audit log.
One workflow per ticket type
A project can hold several workflows, and its workflow scheme maps each ticket type to one of them — bugs can move through Open → Triaged → In Progress → Resolved → Closed while stories follow the Scrum flow. Types without a mapping fall back to the project's default workflow. Initial status, allowed transitions and validation all resolve per type.
In practice
PUT /api/v1/projects/{projectKey}/workflow/transitions/{transitionId}/rules
{"rules": [{"kind": "VALIDATOR", "spec": {"type": "REQUIRED_FIELD", "fieldRef": "assignee", "message": "Assign the ticket before it can start"}}]}See Iskue on your own screen
A demo takes half an hour. A pilot runs on your servers, with your data, from day one.