6.4 Workflow Schemes, Editing Active Workflows & Status Migration
Key Takeaways
- 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.
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.,
BugorSub-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. |
A team lead on the 'Cloud Infrastructure' project requests a mandatory 'Security Review Sign-off' validator on the 'Ready for Deploy' transition. The project currently shares the 'Global IT Workflow Scheme' with 30 other corporate projects. Which administrative course of action fulfills the team lead's request while adhering to Atlassian enterprise governance best practices?
An administrator edits an active workflow in the current Jira Cloud workflow editor and deletes the 'Awaiting Vendor' status, which 40 open issues are in. What happens?
A Jira Administrator updates an active Workflow Scheme by remapping the 'Defect' issue type to a new streamlined workflow. The original workflow included an 'Awaiting Vendor' status that has been completely omitted from the new workflow. Currently, there are 140 open defects residing in the 'Awaiting Vendor' status across three active projects. What will happen when the administrator attempts to associate the updated workflow scheme with the projects?