Workflows and statuses
Decide which statuses an issue can be in, which moves between them are allowed, and which project or tracker follows which workflow.
Admin → Workflows
A workflow is the set of statuses an issue can be in and the moves allowed between them. Every project follows a default workflow, and individual trackers in a project can follow a different one. Workflows and statuses are managed under Admin in the sidebar, on the Workflows and Status tabs.
How statuses and workflows fit together
Statuses belong to the whole workspace — one shared pool. A workflow picks statuses from that pool and places them in its own order. The same status (say, Review) can sit in several workflows at once.
- A status's Name, Category and Color live once, so changing them changes the status in every workflow that uses it. The editor warns you when a status is shared.
- Whether a status is the initial or a final one is set per workflow, so the same status can be final in one workflow and not in another.
- Each status has a category — Todo, In Progress or Done — which is how boards, reports and filters tell open work from finished work.
A new workspace starts with one default workflow holding Todo, In progress, Review and Done.
Create a workflow
- Open Admin and choose the Workflows tab.
- In the Create workflow card, enter a Name and, optionally, a Description.
- Choose Create workflow. It starts with no statuses — add them on the Status tab.
Each workflow card lists its statuses, which projects use it (Used by, marked default or as a tracker override) and its Allowed transitions.
Add, edit and remove statuses
- Open the Status tab. Statuses are grouped by workflow.
- Choose New, pick the Workflow, then either Use existing status (reuse one from the pool) or Create new status (give it a Name, Category and Color).
- Tick Initial status (where new issues start) or Final status (counts as resolved/done) if they apply, then choose Add status.
Click a status in the list to edit it, then Save changes. The bin icon removes it from that workflow only; other workflows that use it keep it.
Allowed transitions
A transition allows one move, from one status to another. Add one in the Allow transition card: pick the Workflow, the From and To statuses, and choose Allow move. Remove one with the bin icon on its chip.
The rule applies to every status change: editing one issue, dragging a card on a board, and bulk edits alike. In a bulk edit, an issue that cannot make the move is left out and the reason is reported.
Rules on a transition
Each transition chip has an Add rules link (it shows a summary once rules exist). Rules decide who may make that move and what must be true of the issue first:
- Only the issue's assignee — nobody else can make this move.
- Only people in these roles — tick one or more roles; none ticked means anyone.
- What must be set first — fields that must have a value, such as description, assignee, due date, labels, story points, sprint, release or any of your custom fields.
- All child issues are done — every sub-issue must be in a final status.
Choose Save rules. A move that breaks a rule is refused with a message that says which rule. Values set in the same edit count, so setting the assignee and moving the issue in one go works.
Which workflow a project follows
- Open the project and choose Settings in its header.
- Under Workflow, pick the Default workflow. It applies to every tracker without an override of its own.
- Below it, pick a different workflow for any tracker that needs one. Each change saves straight away.
Per-tracker overrides are available on plans that include Custom Workflows; without it, every tracker follows the project's default workflow.
Final statuses
Marking a status final is what makes an issue count as resolved. Final statuses are what the All child issues are done rule checks, and they are where a project's Definition of Done gate (if it is set to warn or block) is checked.
Deleting a workflow
The bin icon on a workflow card deletes it, together with its statuses, transitions and auto-close rules. It is refused when:
- it is the default workflow — every project without one of its own falls back to it;
- a project uses it as its default, or a tracker override points at it;
- any issue is still in one of its statuses.
Viewing these tabs needs the workflow read permission; changing them needs workflow update (deleting a workflow needs workflow delete). Owners and Admins have all of these.