6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions

6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions

Quick Summary: In Jira Cloud, workflows represent the business process lifecycle of an issue from inception to completion. A workflow consists of statuses (the state an issue occupies) and transitions (the directional paths connecting those statuses). Every status maps to one of three universal Status Categories (To Do, In Progress, Done), which dictate how Jira's reporting engines, agile boards, and JQL functions interpret work progress. Mastering transition topologies—initial create, direct step-to-step, and global transitions—along with status properties enables administrators to enforce enterprise compliance while maintaining team agility.

---

Statuses and Status Categories Architecture

In company-managed Jira Cloud projects, statuses are defined as global objects managed under Jira Settings > Issues > Statuses. When an administrator creates a status, it becomes part of the global status dictionary and can be reused across any workflow in the site. Each status consists of three core attributes:

1. Name: The human-readable label displayed in the user interface (e.g., Open, In Development, Under Security Review, Closed).
2. Description: Administrative context explaining the purpose and entry criteria for the state.
3. Status Category: The foundational classification that informs Jira's internal calculation engines how to treat issues occupying that status.

+-------------------------------------------------------------------------+
|                        GLOBAL STATUS DICTIONARY                         |
|                     (Jira Settings > Issues > Statuses)                 |
+-------------------------------------------------------------------------+
          |                                  |                        |
          v                                  v                        v
+-----------------------+  +-----------------------+  +-----------------------+
|       TO DO           |  |      IN PROGRESS      |  |         DONE          |
| Category Key: 'new'   |  | Category: 'indeterminate'| Category Key: 'done'   |
| Visual: Grey          |  | Visual: Blue          |  | Visual: Green         |
| Examples:             |  | Examples:             |  | Examples:             |
|  - Backlog            |  |  - In Development     |  |  - Closed             |
|  - Open               |  |  - Code Review        |  |  - Resolved           |
|  - Triaged            |  |  - QA Testing         |  |  - Shipped            |
|  - Ready for Dev      |  |  - Blocked            |  |  - Cancelled          |
+-----------------------+  +-----------------------+  +-----------------------+

The Three Status Categories in Depth

Atlassian groups every workflow status into one of three fixed, non-customizable status categories:

Why Status Categories Matter Across Jira

Status categories are not merely cosmetic color badges; they drive Jira's underlying logic across multiple subsystems:

1. Agile Board Column Mapping: Board columns are mapped to statuses in Board settings > Columns. The board's column colors follow position: the leftmost column is To Do, middle columns are In Progress, and the rightmost column is always shown green (done). Atlassian is explicit that Jira only considers issues in the rightmost column as complete when you complete a sprint, regardless of the status's category. Map every status that means "finished" (Done, Cancelled, Won't Do) to the rightmost column, or those issues roll into the next sprint as incomplete.
2. Durable JQL Filtering: In an enterprise with dozens of teams, individual projects frequently use customized status names (e.g., Team A uses Closed, Team B uses Shipped, Team C uses Live in Production). Rather than writing fragile JQL queries that list every possible status name, administrators and managers can query using the statusCategory field:
   • statusCategory != Done returns all active, incomplete work across every project.
   • statusCategory = "In Progress" returns all work actively consuming team capacity.
   • statusCategory in ("To Do", "In Progress") captures uncompleted backlogs dynamically.
3. Progress Displays: Release and epic progress bars, and many gadgets, group issues by status category (To Do, In Progress, Done). If a team puts its "Shipped" status in the In Progress category, those displays show finished work as still in progress.

---

Transition Topologies: Initial, Direct, and Global

A transition is a directed link in a workflow that allows an issue to move from one status to another. Jira supports three distinct transition types:

  (•) Virtual Start Point
   |
   | [Initial Create Transition]
   v
+------------+       Direct Transition ('Start Dev')       +-------------+
|   TO DO    | ------------------------------------------> | IN PROGRESS |
+------------+                                             +-------------+
      ^                                                           |
      |                Direct Transition ('Reject QA')            |
      +-----------------------------------------------------------+
                                                                  |
                               Direct Transition ('Pass QA')      |
                                                                  v
                                                           +-------------+
=================== GLOBAL TRANSITION ('Cancel Issue') ==> |    DONE     |
(Executable from ANY status in the workflow: To Do,        +-------------+
 In Progress, In Review, or Done)                                 

1. The Initial Create Transition

Every workflow has exactly one initial transition originating from the virtual start point (represented by a black dot in the visual workflow designer). This transition executes during the issue creation transaction.

• It has no source status because the issue does not yet exist in the database prior to execution.
• It cannot have Conditions attached to it, because conditions evaluate issue attributes that have not yet been stored.
• It can have Validators (e.g., verifying mandatory fields or user permissions) and Post Functions (e.g., setting default values, assigning the issue, and firing the Issue Created system event).

2. Direct Transitions (Step-to-Step)

A direct transition has one or more explicitly defined source statuses and a single destination status.

• Example: A transition named Start Progress that moves an issue strictly from To Do to In Progress.
• Governance Advantage: Direct transitions enforce strict stage gates and process compliance. An issue cannot bypass required phases (such as skipping Code Review to jump straight from In Development to Done).
• Administrative Trade-off: Overusing direct transitions in complex workflows creates visual spaghetti in the workflow editor and can lead to transition bottlenecks if teams encounter legitimate non-linear operational paths.

3. Global Transitions ("All-to-One")

A global transition lets an issue move to the target status from any status. In the workflow editor you create it by choosing Any status as the "from" status (the legacy editor used a checkbox labeled "Allow all statuses to transition to this one"). The diagram shows it as an Any status or All marker pointing to the target status. The current editor also lets one transition start from several selected statuses.

• Execution Scope: Users can execute a global transition regardless of what status the issue currently occupies.
• Common Use Cases: Terminal or exceptional actions, such as Cancel Issue, Escalate to Tier 3, On Hold, or Close Ticket.
• Governance Caution: While global transitions simplify workflow maintenance by eliminating dozen of repetitive direct transition arrows, they permit users to bypass intermediate quality and review gates. For example, if a global Close transition exists, a developer could close an issue directly from To Do without ever entering development, logging time, or passing testing.

---

Workflow Step & Transition Properties

Workflow Properties are key-value pairs configured on statuses (steps) or transitions in the workflow editor (Select Status/Transition > View Properties). They alter Jira's runtime behavior for issues residing in that specific status or passing through that transition, operating as granular overrides on top of the project's permission scheme.

The jira.issue.editable Property

By default, any user with the Edit Issues project permission can edit fields on an issue, regardless of its status. However, once an issue reaches a terminal status like Closed or Approved, organizations often require that the issue become strictly read-only.

• Key: jira.issue.editable
• Value: false (or true)
• Behavior: When set to false on a status, issues in that status can't be edited (the edit option disappears), although they can still be transitioned. Users cannot edit summary, description, estimates, or custom fields, even if the project permission scheme explicitly grants them Edit Issues.

Status-Specific Permission Overrides (jira.permission.*)

Administrators can restrict specific project permissions dynamically based on the current status of an issue using the jira.permission.* property prefix:

# Only allow members of the 'Compliance Officers' project role (Role ID: 10005) to edit the issue in this status:
jira.permission.edit.projectrole = 10005

# Restrict issue editing in this status to a specific Jira group:
jira.permission.edit.group = jira-administrators

# Prevent all users from adding comments while the issue is in this status:
jira.permission.comment.denied = true

# Restrict who can be assigned the issue while in this status to a specific role:
jira.permission.assignable.projectrole = 10002

[!IMPORTANT] Workflow properties evaluate in addition to project permission schemes. A user must possess the global and project permission and satisfy the workflow property restriction. Properties can restrict access further than the permission scheme, but they cannot grant permissions to a user who lacks them in the permission scheme.

---

Designing Lean Workflows: Avoiding the 20+ Status Anti-Pattern

A frequent failure mode in enterprise Jira administration is status sprawl—the creation of bloated workflows containing 15, 20, or even 30 distinct statuses attempting to document every micro-action:

[Sprawling Workflow Anti-Pattern]:
Open -> Assigned -> Dev Queue -> Dev In Progress -> Dev Paused -> Dev Blocked ->
PR Created -> Under Review -> Review Approved -> QA Queue -> QA In Progress ->
QA Blocked -> Ready for Staging -> Deploying -> UAT Queue -> UAT In Progress -> Done

Why Status Sprawl Destroys Team Velocity

1. Board Usability Failure: Kanban and Scrum boards become unreadable horizontal marathons. Columns must be scrolled indefinitely, and daily standups bog down in column management.
2. Transition Fatigue: Team members spend excessive time deciphering which transition button to click, leading to issues being left in obsolete statuses.
3. Fragile Automation and Reporting: Every automation rule, board filter, and dashboard gadget requires complex compound JQL clauses to account for dozens of intermediate statuses.
4. Inaccurate Cycle Time Metrics: Cycle time and lead time calculations become distorted because issues spend arbitrary periods sitting in artificial queue statuses.

Lean Workflow Architecture Principles

Atlassian recommends structuring workflows around major operational boundaries where handoffs between different roles or status categories occur:

1. Model States of Being, Not Micro-Actions: A status should represent a meaningful phase where work is actually occurring or waiting for a major handoff (e.g., Backlog, In Progress, Under Review, Done).
2. Capture Micro-States in Fields or Flags: Instead of creating Dev Blocked and QA Blocked statuses, use the native Jira Flagged feature (which turns the card yellow on boards) or a custom dropdown field (Blocker Reason).
3. Use Sub-tasks for Multi-Step Processes: If a user story requires development, security scanning, and documentation, represent these as child sub-tasks under a lean parent workflow rather than forcing the parent story through 12 linear statuses.
4. Limit Workflows to 4–8 Statuses: An effective, scalable enterprise workflow rarely requires more than 5 to 7 well-defined statuses.