Study guide
6.4 Workflow Schemes, Editing Active Workflows & Status Migration
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.4 Workflow Schemes, Editing Active Workflows & Status Migration
Key Takeaways Explain This Topic AI
A workflow scheme maps issue types to workflows, with a default workflow for any issue type that isn't mapped explicitly.
The current workflow editor publishes changes to every project using the workflow when you select Update workflow; the legacy editor staged changes in drafts.
Deleting a status that still has issues, remapping an issue type to another workflow, or switching a project's scheme makes Jira map existing issues to valid statuses.
The editor lists the projects that use a workflow, so check it before publishing a change to a shared workflow.
For a single team's customization, copy the shared workflow, change the copy, and give that project its own workflow scheme.
Last updated: September 2026
6.4 Workflow Schemes, Editing Active Workflows & Status Migration
Quick Summary: In Jira Cloud, a workflow scheme maps each issue type in a project to a workflow. The current workflow editor publishes changes to every project that uses a workflow as soon as the admin selects Update workflow . The legacy editor staged changes in a draft instead. When an admin switches a project to a different scheme, remaps an issue type to a different workflow, or removes a status that still has issues, Jira makes them map existing issues to valid statuses. The "copy and branch" pattern keeps one team's customization from disrupting everyone who shares a workflow.
Workflow Schemes Architecture
A Workflow Scheme defines which workflows apply to which issue types within one or more company-managed projects ( Jira Settings > Issues > Workflow schemes ). It serves as a central hub of process management: +-------------------------------------------------------------------------+
- | ENTERPRISE WORKFLOW SCHEME |
- | 'Global Engineering Workflow Scheme' |
- +-------------------------------------------------------------------------+
- | Issue Type Mapping: |
- | - (All unassigned issue types) ──► Standard Task Workflow |
- | - Bug ──► Software Defect Workflow |
- | - Story ──► Agile Feature Workflow |
- | - Epic ──► Portfolio Delivery Workflow |
- | - Sub-task ──► Simple Sub-task Workflow |
- +-------------------------------------------------------------------------+
- | |
- v v
- +-----------------------+ +-----------------------+
- | PROJECT A | | PROJECT B |
- | Mobile Engineering | | Web Core Platform |
- +-----------------------+ +-----------------------+
- Core Structural Rules of Workflow Schemes
The Default Workflow Catch-All: Every workflow scheme must have a designated default workflow assigned to (All unassigned issue types) . Any issue type present in the project that does not have an explicit mapping automatically inherits this default workflow.
Explicit Issue Type Mappings: Administrators can assign specific issue types (e.g., Bug or Sub-task ) to unique, tailored workflows that include specialized statuses, transition screens, and validation rules.
Multi-Project Reusability: A single workflow scheme can be associated with dozens or hundreds of projects. Updating the scheme or its underlying workflows immediately impacts every project linked to that scheme.
- Editing Active Workflows
- The Current Workflow Editor: Edit and Publish Instantly
In the Jira Cloud workflow editor, you edit statuses, transitions, and rules in one view, then select Update workflow to publish the changes immediately to every project that uses the workflow. Until you select Update workflow, nothing changes for users. You can also discard your changes and return to the workflow's previous state.
Key behaviors to know:
See who's affected before publishing. The editor shows the relevant projects that use the workflow, so you can tell whether a change will reach other teams.
Delete statuses from an active workflow. When you delete a status that still has issues, Jira immediately walks you through moving those issues to another status.
Add outgoing transitions safely. If a status has no outgoing transitions (apart from global ones), you can add new regular or global transitions to it.
Share transitions. One transition can start from several selected statuses, with a single set of rules.
The Legacy Editor: Draft Workflows
Older documentation, and some older sites, show the legacy editor . Editing an active workflow there creates a draft . Users keep running the published version until an admin selects Publish draft (optionally saving a backup copy of the original) or Discard draft . In that editor you can't delete a status from an active workflow's draft while issues are in it.
Exam angle: If a question describes a draft, the published version stays live until someone publishes the draft. If it describes the current editor, changes go live when the admin selects Update workflow, and status deletions trigger an immediate migration of affected issues.
The Workflow Migration Wizard
The Workflow Migration Wizard is an essential data integrity tool in Jira Cloud. It launches automatically whenever an administrator:
Associates an active project with a different Workflow Scheme ( Project Settings > Workflows > Switch Scheme ).
Modifies an active Workflow Scheme to point an issue type to a different workflow.
Removes a status that still has issues from an active workflow (in the current editor, the move happens as part of publishing). +-------------------------------------------------------------------------+
- | WORKFLOW MIGRATION WIZARD FLOW |
- +-------------------------------------------------------------------------+
- | Step 1: Issue Analysis |
- | - Jira analyzes the database for all issues of affected issue types. |
- | - Identifies issues whose current status does NOT exist in target wf. |
- +-------------------------------------------------------------------------+
- │
- ▼
- +-------------------------------------------------------------------------+
- | Step 2: Status Mapping Interface |
- | - Prompts administrator to map each orphaned status: |
- | 'In Triage' (Old Workflow) ──► [Select Target Status ▼] |
- | 'Awaiting Hardware' (Old) ──► [Select Target Status ▼] |
- +-------------------------------------------------------------------------+
- │
- ▼
- +-------------------------------------------------------------------------+
- | Step 3: Background Bulk Execution |
- | - Updates issue status IDs in the database. |
- | - Re-evaluates Status Categories (To Do, In Progress, Done). |
- | - Writes change history entries for all migrated issues. |
- | - Triggers search re-indexing for agile boards and JQL queries. |
- +-------------------------------------------------------------------------+
- The Status Mapping Requirement
If the target workflow does not contain an exact, 1:1 match for every status currently occupied by existing issues, the wizard halts execution and requires the administrator to select a valid destination status for each affected status. Jira will never allow issues to exist in an orphaned state without a corresponding valid status in the new workflow.
Operational Impact During Migration
For small projects, the migration wizard completes in seconds. In enterprise instances with tens of thousands of issues, the migration executes as an asynchronous background task. During this window:
Issue data is preserved without corruption.
Status category alignments are recalculated.
Agile board columns update automatically once re-indexing concludes.
Enterprise Workflow Governance & Multi-Project Impact
In large Jira Cloud environments, the greatest administrative risk is unintentional collateral damage caused by editing shared schemes.
The Shared Scheme Disaster Scenario
Consider a Jira instance where 45 development teams share a single Enterprise Software Workflow Scheme . A project lead from the Mobile team asks the Jira Administrator to make the custom field Mobile OS Version mandatory whenever an issue transitions to Resolved .
The Critical Error: The administrator opens the shared Enterprise Software Workflow , adds a field-required validation rule for Mobile OS Version on the Resolve transition, and selects Update workflow .
The Result: The validator instantly applies to all 45 projects! The other 44 teams (who develop backend microservices, web apps, and data pipelines) do not have the Mobile OS Version field on their transition screens. Consequently, hundreds of developers across the company are immediately locked out of resolving their tickets, creating an enterprise-wide Sev-1 administrative incident.
The "Copy and Branch" Best Practice
To prevent shared scheme disruptions, Jira administrators should always follow the "Copy and Branch" pattern whenever a project-specific workflow modification is requested: [Shared Enterprise Workflow]
- │
- ├──► 1. Inspect 'View Projects' to verify scheme usage
- │
- ├──► 2. Click 'Copy' to create 'Mobile Engineering Workflow'
- │
- ├──► 3. Configure custom validators/screens on the copied workflow
- │
- ├──► 4. Create new 'Mobile Workflow Scheme' (or copy existing scheme)
- │
- └──► 5. Associate Mobile Project with the new scheme via Migration Wizard
Governance Phase Administrative Action Best Practice Rule
1. Impact Assessment Navigate to Jira Settings > Issues > Workflows and inspect the Associated Schemes and Projects column. If more than one project uses the workflow, never edit the active workflow directly for single-team requests.
2. Workflow Copy Select Actions > Copy on the target workflow. Name the copy clearly (e.g., WF - Mobile Platform - v2 ). Retain descriptive naming conventions reflecting team scope and versioning.
3. Isolated Configuration Add the requested transitions, validators, conditions, or screens to the copied workflow. Test the changes in a dedicated staging or sandbox project before production rollout.
4. Scheme Association Create or copy a Workflow Scheme, map the affected issue types to the copied workflow, and associate the project. Run the Workflow Migration Wizard during off-peak hours for large issue volumes.
5. Audit & Cleanup Record the rationale in the change ticket and verify that inactive workflows are periodically reviewed. Regularly prune unused, deprecated workflow copies to prevent administrative clutter.