JIRA Workflows
A JIRA workflow defines the exact path an issue travels from the moment it is created to the moment it is closed. Every status an issue can have, and every transition between those statuses, forms part of the workflow. JIRA enforces these rules automatically — a developer cannot move an issue to "Done" without passing through the steps the workflow defines. This discipline keeps the entire team following the same process without needing manual supervision.
Core Workflow Concepts
Understanding three fundamental concepts is necessary before building or modifying any workflow: Statuses, Transitions, and Conditions.
| Concept | Definition | Example |
|---|---|---|
| Status | The current stage of an issue in the workflow | To Do, In Progress, In Review, Done |
| Transition | The action that moves an issue from one status to another | "Start Work" moves issue from To Do → In Progress |
| Condition | A rule that must be met before a transition is allowed | Only the Assignee can click "Mark as Done" |
| Validator | Checks that specific fields are filled before a transition completes | The "Resolution" field must be set before closing an issue |
| Post Function | An automatic action that runs immediately after a transition succeeds | Automatically assign the issue to the QA Lead after "Submit for Review" |
The Default JIRA Workflow
Every new Software project in JIRA starts with a simple default workflow. This workflow covers the basic development cycle and suits most small teams starting with JIRA.
| Current Status | Transition Name | Next Status |
|---|---|---|
| To Do | Start Progress | In Progress |
| In Progress | Stop Progress | To Do |
| In Progress | Mark as Done | Done |
| Done | Reopen | To Do |
A Real-World Software Development Workflow
Most development teams extend the default workflow to match their actual delivery process. A typical software team includes code review and QA testing stages before closing an issue.
| Step | Status | Who Acts | Transition to Next |
|---|---|---|---|
| 1 | Backlog | Product Owner | Add to Sprint → To Do |
| 2 | To Do | Developer | Start Work → In Progress |
| 3 | In Progress | Developer | Submit for Review → In Review |
| 4 | In Review | Tech Lead | Approve → Ready for QA |
| 4a | In Review | Tech Lead | Reject → In Progress (back) |
| 5 | Ready for QA | QA Engineer | Start Testing → In Testing |
| 6 | In Testing | QA Engineer | Pass → Done |
| 6a | In Testing | QA Engineer | Fail → In Progress (back to developer) |
| 7 | Done | — | Reopen → To Do (if regression found) |
Workflow Diagram — Visual Flow
The workflow above can be visualized as a series of connected boxes. Each arrow represents a transition. Backward arrows show the rework path.
| Issue Flow Through Statuses | ||||||||
|---|---|---|---|---|---|---|---|---|
| Backlog | → | To Do | → | In Progress | → | In Review | → | Done |
| ↑ Rejected | → Ready for QA → In Testing | |||||||
| ↑ QA Fail | ||||||||
Workflow Conditions
Conditions restrict who can execute a transition. Without conditions, any user could move any issue to any status, which removes process control. Adding conditions ensures only authorized roles perform specific transitions.
| Condition Type | Effect | Example Use |
|---|---|---|
| User Is in Group | Only users in a specific JIRA group can perform the transition | Only "QA Engineers" group can transition to "Done" |
| User Is in Role | Only users with a specific project role can perform the transition | Only "Developer" role can click "Submit for Review" |
| Only Assignee | Only the current assignee of the issue can perform the transition | Only the assigned developer can start work on an issue |
| Permission Condition | Checks for a specific JIRA permission before allowing the transition | User must have "Resolve Issue" permission |
Workflow Validators
Validators check that required fields are filled before a transition completes. If a field is empty, JIRA blocks the transition and shows an error message until the user provides the missing information.
| Transition | Validator Applied | Why It Matters |
|---|---|---|
| Submit for Review | Story Points field must not be empty | Ensures all work is estimated before going to review |
| Mark as Done | Resolution field must be set | Forces the resolver to document the outcome |
| Close Issue | Fix Version field must be set | Links the fix to a specific software release version |
| QA Pass | At least one comment must exist | Requires QA to document test results before closing |
Post Functions
Post functions trigger automatic actions the moment a transition completes successfully. They reduce manual work by automating repetitive steps that always follow a transition.
| Transition | Post Function | Result |
|---|---|---|
| Submit for Review | Assign issue to Component Lead | Tech lead receives an assignment notification automatically |
| QA Pass → Done | Set Resolution to "Done" | Issue resolution field populates without manual entry |
| Start Progress | Set "Start Date" field to current date | Tracks when work actually began on the issue |
| Reopen | Clear the Resolution field | Removes the previous resolution so the issue is active again |
Global vs Local Transitions
A transition can be global or local depending on which statuses it applies to.
| Type | Applicable From | Example |
|---|---|---|
| Global Transition | Any status in the workflow | "Cancel Issue" — moves the issue to "Cancelled" from any status |
| Local Transition | Only from a specific status | "Submit for Review" — only available from "In Progress" |
How Workflows Connect to Boards
The columns on a JIRA board map directly to workflow statuses. When a team drags a card from "In Progress" to "In Review" on the board, they are actually executing a transition in the workflow. The board is the visual layer on top of the workflow engine underneath.
| Board Column | Workflow Statuses Mapped |
|---|---|
| To Do | To Do, Backlog |
| In Progress | In Progress, In Review, Ready for QA |
| Testing | In Testing |
| Done | Done, Closed, Resolved |
Workflow Schemes
A Workflow Scheme connects workflows to issue types within a project. Different issue types can use different workflows in the same project. This is a Company-Managed project feature.
| Issue Type | Workflow Assigned |
|---|---|
| Story | Software Development Workflow |
| Bug | Bug Fix Workflow (includes "Duplicate" and "Won't Fix" statuses) |
| Task | Simple Task Workflow (To Do → In Progress → Done only) |
| Epic | Epic Workflow (To Do → In Progress → Done) |
Summary
JIRA workflows provide the rules engine that governs how issues move through a project's lifecycle. Statuses represent the stages. Transitions represent the movements between stages. Conditions, validators, and post functions add intelligence and automation to each transition. Boards display workflow statuses visually. Workflow schemes connect different workflows to different issue types within the same project. A well-designed workflow eliminates confusion about process and creates a consistent, auditable record of how work gets done. With a clear understanding of workflows, the focus now shifts to the visual tools that make workflow statuses visible to the whole team — JIRA Boards.