Workflows, Transitions, and Status Configuration
Statuses versus transitions
A status is where an issue is; a transition is the arrow that moves it, and it is the only place you attach a condition (who may), a validator (what must be true), a screen (what must be captured), and post functions (what happens next: set resolution, clear a field, fire an event). Post functions run in order, and the event fired at the end is what notification schemes react to.
Schemes and drafts
The workflow scheme maps each issue type to a workflow. Editing a live workflow changes every project sharing it, so use the draft → publish cycle with a backup so you can preview migration of in-flight issues. Status categories (To Do, In Progress, Done) drive boards, sprint completion and the statusCategory JQL function - a status in the wrong category breaks reports even when the workflow diagram looks correct.
Traps
- Adding a status to a workflow does not make it reachable; you must also add transitions in and out.
- A transition condition is not a permission check - both are evaluated.
- The Create transition is the initial transition and can carry a screen and validators.
- Resolution is a separate field from status; a status category of Done and a resolution of Done are different things.
- A workflow or status in use cannot be deleted until it is removed from every scheme.
- Conditions on "All" transitions apply to every arrow they cover.
Rule of thumb: for every status, trace one incoming and one outgoing transition. No incoming means unreachable; no outgoing means a dead end.