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

  1. Open Admin and choose the Workflows tab.
  2. In the Create workflow card, enter a Name and, optionally, a Description.
  3. 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

  1. Open the Status tab. Statuses are grouped by workflow.
  2. 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).
  3. 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.

A status cannot be removed while any issue is still in it, or while a board column is mapped to it. Move those issues (or remove the column) first.

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.

A workflow with no transitions saved allows every move. As soon as you add the first one, only the moves you have listed are allowed — so add every move your team needs, not just the one you were thinking of.

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

  1. Open the project and choose Settings in its header.
  2. Under Workflow, pick the Default workflow. It applies to every tracker without an override of its own.
  3. 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.