Short definition
A Jira workflow is the set of statuses an issue can occupy and the transitions allowed between them. Every issue type in every project has a workflow - even a default 'To Do / In Progress / Done' is a workflow. Admins design workflows with conditions (who can transition), validators (what must be true), and post-functions (what happens automatically) on each transition.
What a workflow is made of
A workflow has three first-class pieces:
- Statuses - the named states an issue can be in. Statuses are global; the same Status object can be used in many workflows.
- Transitions - the allowed moves from one status to another. Transitions are directional: an arrow from In Progress to Done is a different transition than the reverse, and each can have its own rules.
- Initial transition - the implicit transition that fires on issue creation, which sets the starting status.
Each transition can carry:
- Conditions - who is allowed to perform this transition (a role, a group, the reporter).
- Validators - what must be true at the moment the user clicks the button (assignee set, resolution picked).
- Post-functions - what should happen automatically when the transition completes (set Resolution, update a custom field, send a notification, fire a webhook).
Conditions are evaluated to show or hide the button. Validators are evaluated to allow or block the click. Post-functions run after the click succeeds.
Status categories
Jira groups every status into one of three status categories: To Do (blue/grey), In Progress (yellow), or Done (green). This category drives the colour of the status badge, the board column behaviour, and several reports.
The category is separate from the status name. You can have ten different In Progress statuses (Coding, Code Review, Awaiting QA, etc.), all of which roll up to the “In Progress” category and all of which appear in the In Progress lane of an agile board.
Workflow schemes
A Workflow Scheme maps each issue type in a project to a workflow. A single project can use one workflow for Bugs (with extra triage statuses) and a different workflow for Stories (simpler agile flow).
Workflows are some of the most-modified configuration in Jira because they encode team process. They’re also the easiest place to over-engineer: every status that doesn’t add information becomes friction. A good rule is that every status should correspond to a real waiting state or a real handoff. If “In Code Review” and “Awaiting QA” are essentially “someone else is now working on it,” consider collapsing them.
Workflow validation traps
Two common gotchas:
- The Done transition doesn’t set Resolution by default. If your workflow puts an issue into Done without a post-function or a screen that captures Resolution, the issue counts as “open” in many reports forever. Always wire Resolution onto the transition into a closed status.
- Conditions hide buttons silently. If a user can’t see the button they expect, it’s usually a permission or role condition on the transition, not a bug. Trace the transition’s condition list in workflow edit view.
Common questions
What is a Jira workflow?
A Jira workflow is the set of statuses an issue can occupy and the transitions allowed between them. Every issue type in every project has a workflow - even a default 'To Do / In Progress / Done' is a workflow. Admins design workflows with conditions, validators, and post-functions on each transition to control who can move issues and what happens when they do.
What's the difference between status and resolution in Jira workflows?
Status is where the issue is now (Open, In Progress, Done). Resolution is how it ended (Fixed, Won't Do, Duplicate). An issue is 'resolved' once it has any non-empty Resolution - reaching the Done status doesn't automatically set Resolution. Workflows usually set Resolution via a post-function on the transition into Done.
Can the same workflow be used by multiple projects?
Yes. Workflows are global objects, assigned to projects via Workflow Schemes. The same workflow can be shared across dozens of projects - and most large Jira instances consolidate aggressively to keep configuration manageable.
What's a workflow validator vs. a post-function?
A validator runs *before* the transition completes and can block it if a condition isn't met ('the assignee must be set before this transition'). A post-function runs *after* the transition completes and performs an action ('clear the assignee', 'send a notification', 'update a custom field').