Study guide
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions
Key Takeaways Explain This Topic AI
Company-managed statuses are global objects, and every status belongs to one of three fixed categories: To Do (grey), In Progress (blue), or Done (green).
Status categories drive progress displays and category-based JQL such as statusCategory != Done, but sprint completion depends on the board's rightmost column, not the category.
Workflows have an initial create transition (which can't have conditions), direct transitions from chosen statuses, and global 'Any status' transitions.
Workflow properties (such as jira.issue.editable and jira.permission.*) provide status-specific overrides that restrict actions even when global permission schemes grant access.
Lean workflow architecture prioritizes minimal, high-value status handoffs over bloated workflows with 20+ statuses, utilizing custom fields or checklists to represent micro-states.
Last updated: September 2026
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:
Name: The human-readable label displayed in the user interface (e.g., Open , In Development , Under Security Review , Closed ).
Description: Administrative context explaining the purpose and entry criteria for the state.
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:
Status Category Internal Key UI Badge Color Operational Definition & Lifecycle Meaning
To Do new Grey Work that has been identified, scheduled, or triaged but has not yet commenced. Issues in this category represent backlogged demand or incoming requests awaiting action.
In Progress indeterminate Blue Work that is actively being performed, investigated, reviewed, or held in an intermediate waiting state. It represents active Work in Progress (WIP).
Done done Green Work that has reached a terminal conclusion, whether successfully completed (e.g., Resolved , Done , Shipped ) or abandoned (e.g., Cancelled , Rejected , Won't Fix ).
Why Status Categories Matter Across Jira
Status categories are not merely cosmetic color badges; they drive Jira's underlying logic across multiple subsystems:
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.
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.
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.
- Transition Parameter Initial Create Transition Direct Transition Global ("All") Transition
- Source Status None (Virtual Start Point) Specific named status(es) Any status in the workflow
- Target Status Initial workflow status Single specific status Single specific status
- Supports Conditions? No (Issue does not yet exist) Yes Yes
- Supports Validators? Yes Yes Yes
- Supports Screens? Yes (Typically Create Screen) Yes (Transition Screen) Yes (Transition Screen)
Primary Architectural Role Instantiates new issues Enforces sequential process stages Provides universal access to terminal/exception states
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
Board Usability Failure: Kanban and Scrum boards become unreadable horizontal marathons. Columns must be scrolled indefinitely, and daily standups bog down in column management.
Transition Fatigue: Team members spend excessive time deciphering which transition button to click, leading to issues being left in obsolete statuses.
Fragile Automation and Reporting: Every automation rule, board filter, and dashboard gadget requires complex compound JQL clauses to account for dozens of intermediate statuses.
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:
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 ).
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 ).
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.
Limit Workflows to 4–8 Statuses: An effective, scalable enterprise workflow rarely requires more than 5 to 7 well-defined statuses.