Atlassian is removing Jira Cloud’s old (legacy) workflow editor. The final rollout runs from 13 July 2026 and completes by 26 July 2026 through Jira’s seasonal releases, after which every workflow edit happens in the new editor. You don’t need to migrate anything – existing workflows keep running and stay editable – but you do need to relearn where familiar controls live.
This guide covers what changed, how the two editors differ, how to do the everyday jobs in the new editor, and how to get unstuck when a control you relied on has moved or been renamed.
What changed and when
Jira Cloud has had two workflow editors running side by side for a few years: the old editor, where changes were spread across several pages and held in a draft until you published, and the newer editor, which puts statuses, transitions, and rules in a single diagram view. Atlassian has been closing the feature gap between them and is now shutting the old one down.
The timeline is specific. Atlassian’s Jira Cloud Admins announcement states the final removal of the old workflow editor begins on 13 July 2026 and completes by 26 July 2026 through Jira’s seasonal releases. During that window the Open workflow in old editor option disappears from the editor toolbar, and once the rollout reaches your site, workflow editing happens only in the new editor. Atlassian reports that over 95% of customers already publish their global workflows from the new editor, which is the practical reason the company felt comfortable retiring the old one.
The reassuring part: there is no data migration. Your existing workflows, including every condition, validator, and post-function you built over the years, continue to work and remain editable in the new editor. Nothing needs to be rebuilt. The work is entirely about familiarity – knowing where each control moved and how the editing model itself has changed.
The biggest conceptual shift is that the new editor does not use draft workflows. In the old editor, edits to an active workflow were staged in a draft and published when ready, and you could keep the pre-edit version as an inactive backup. In the new editor, admins edit the published workflow directly and either select Update workflow to apply changes or discard them. That is faster, and it removes several old restrictions, but it also changes how you should protect yourself against mistakes, which is covered below.
How the old and new editors differ
Most of what admins call “changes” are really renames and consolidations. The underlying capabilities are the same; the labels and the editing flow are not. This table maps the pieces you already know to their new homes.
| Old editor | New editor | What it means for you |
|---|---|---|
| Conditions | Restrict transition | Controls who can move a work item and when. Same logic, new label. |
| Validators | Validate details | Checks field values before a transition completes. If it fails, the transition and any follow-on actions don’t run. |
| Post-functions | Perform action | Automatic actions that run once a transition completes – assign, comment, set a field, trigger a webhook. |
| Screen configuration | Request input | Shows a screen during a transition to collect input from the user. |
| Draft workflows | Direct edit of the published workflow | You edit live and publish with Update workflow, or discard before publishing. |
| Save original as an inactive backup | Discard or Update, no automatic backup | Copy the workflow first if you want a rollback point (see Troubleshooting). |
| Text mode (works with steps) | Text view (inspects workflow logic) | Both give a text-based way to read complex workflows, but they are not the same tool. |
The draft is gone, and so are some old limits
Because the new editor edits the published workflow rather than a draft, several restrictions the old editor imposed on active workflows no longer apply. In the old editor you couldn’t delete statuses from an active workflow, and if a status had no outgoing transitions (excluding global transitions) you couldn’t add new outgoing ones without copying the workflow first. In the new editor you can delete statuses in active workflows, and you can add outgoing transitions – regular or global – to a status that had none. When you delete a status, the editor immediately walks you through moving any work items in that status to a new one, so nothing is left stranded.
The honest trade-off is the safety net. The old editor let you keep your original workflow as an inactive backup when you published a draft. The new editor gives you Discard before you publish, but once you select Update workflow the change is live with no automatic saved copy of the previous version. For anything touching a heavily used workflow, treat this as the moment to make your own backup rather than trusting an implicit one.
Rules were renamed, not removed
The new editor groups everything under three rule categories on a transition: Restrict transition, Validate details, and Perform action. Every condition, validator, and post-function from the old editor maps into one of these – Atlassian’s documentation publishes the full mapping, so a Permission Condition becomes a restriction, a Field Required Validator becomes a Validate details rule, and Trigger a Webhook becomes a Perform action. One item did change substance: the old User Permission Validator has been sunsetted, and Atlassian directs you to the Validate that people have a specific permission rule instead.
If you build automation on top of transitions – for example clearing a resolution on reopen, or firing a webhook to another system – it’s worth revisiting how those rules are sequenced after the rename. For anything beyond transition-level rules, our guide to setting up Jira automation rules covers the separate automation engine that often does this work more transparently than a stack of post-functions.
How to work in the new editor
The interface is a single canvas: a toolbar for adding statuses, transitions, and rules; a diagram you drag to arrange; a details panel for whatever you select; and a panel showing which spaces use the workflow before you publish. Here are the jobs you’ll do most often.
Open a workflow to edit it
From a company-managed space:
- Select Settings, then Work items.
- Select Workflows, then find the workflow you want to change.
- Select More actions (the ••• menu), then Edit to open the workflow diagram in the editor.
From a team-managed space:
- Go to Space settings, then Work types, and select a work type.
- Select Edit workflow.
Built-in workflows can’t be edited directly. If you’re starting from one, copy it first and customize the copy.
Add or change a rule on a transition
Atlassian’s guide to editing workflow rules documents each rule type; the short version:
- Select the transition line or its label in the diagram to open the transition details.
- Select Add in the Rules panel within the transition details.
- Choose a rule under Restrict transitions, Validate details, or Perform action.
- Configure the rule to define its behavior.
- Select Add to apply it to the workflow.
Sequence matters. If you need to clear the Resolution field when reopening a work item, add the clear-field Perform action so it runs in the right order. And keep Validate details rules lean – a misconfigured validator can silently block work items from being created or transitioned. Complex gating logic usually belongs in a Restrict transition rule rather than a validator.
Share one transition across several statuses
The old editor made you create a transition and then reuse it status by status. In the new editor, when you create a transition or edit an existing one, you select multiple From statuses so a single set of rules and properties applies to all of them at once. This is the cleanest way to build a “can be sent back to In Progress from anywhere” style transition without duplicating rules.
Check which spaces use the workflow before you publish
Before selecting Update workflow, review the panel that lists the spaces relying on this workflow. This is the guardrail that replaces the old draft-and-backup dance: because a shared workflow can sit behind many spaces and work types, confirm the blast radius of your change before it goes live. When you’re satisfied, publish with Update workflow; if not, discard and start over.
Read complex workflows with text view and Rovo
For tangled workflows, the new editor includes a text view to inspect and edit workflow logic as an alternative to the diagram. Atlassian has also wired its Rovo assistant into workflows: open Rovo Chat and enter /manage-jira-workflows to explain a workflow, add or remove a status, adjust transitions, or create and delete rules in plain language, or use /explain-workflow from a work item’s status dropdown to understand how something moves. Treat these as reading aids and drafting help, not as a substitute for reviewing the published result yourself.
Troubleshooting
“Open workflow in old editor” is missing. That option is removed during the 13-26 July 2026 rollout. Once it’s gone from your site, there’s no way back to the old editor – the workflow is the same, only the editing surface changed. Use the rule mapping above to find your controls.
A rule I used to have seems to be gone. It’s almost certainly renamed rather than deleted. Conditions are now restrictions, validators are Validate details, and post-functions are Perform action. The one genuine removal is the User Permission Validator, which is sunsetted; replace it with the Validate that people have a specific permission rule.
A Marketplace app’s transition rule looks different. Atlassian recently added the ability to preview Marketplace (third-party) transition rules inside the new editor, and has said a consolidated “View all” experience for rules is still coming. If a third-party rule doesn’t display the way it did in the old editor, that’s the area still being finished – the rule itself continues to run.
I published a change I didn’t mean to. The new editor has no automatic backup of the pre-edit workflow. Before editing anything important, copy the workflow so you have a known-good version to fall back on, and lean on Discard while you’re still editing. Once you select Update workflow, the change is live for every space using that workflow.
The workflow won’t let me edit it. If it’s a built-in workflow, you can’t change it – copy it and edit the copy. If it’s shared, remember that your edit now applies to every space listed in the relevant-spaces panel; if that’s not what you want, copy the workflow, change the copy, and reassign it through the workflow scheme.
None of this changes the shape of your process. Statuses are still the states a task moves through, transitions are still one-way (you need two to move a work item back and forth), and loop transitions still let you open a screen or fire an action without changing status. If you run approval-heavy processes, the same principles apply in Jira Service Management – our Jira Service Management ITSM setup guide walks through how these workflows sit inside a service project. And if the editor change has you weighing whether Jira still fits how your team works, our roundup of the best Jira alternatives and our breakdown of Jira pricing and plans are a useful sanity check before you commit more time to rebuilding around a new interface.
Sponsored
