Default Experience: New Workflow Editor

[#1]

---

Starting March 30, 2026, we will direct all customers to new workflow editor and remove the ability to set editor preference to old editor. The UI will preserve the the ability to switch to the old editor for a user for the workflow editing session.

---

Why are we doing this?

Also read: Old workflow editor sunset

Today, over 90% of users publishing workflows are doing it in the new experience. With the positive feedback we are receiving and the upcoming deprecation of the old workflow designer starting June 2026, we want to ensure all the remaining admins using the old workflow designer get the opportunity to familiarise themselves with the new interface and adopt it.

During this time, we are also keenly looking out for feedback so that we can unblock all customers to adopt the new workflow editor.

Get up to speed on the new editor

We know that change is not easy, but we are confident that the new workflow editor will make workflows visually clearer, simpler to learn, and quicker to update. In our effort to make this transition smoother here are two resources to help you get familiar with the new editor:

1. What is the new workflow editor?

2. Video walkthrough: New vs old workflow editor | Demo Den | Atlassian

What will happen in March 2026?

With over 95% of our customers already being directed to the new editor, we are removing the ability to explicitly set preference for the old workflow editor.

• This means remaining 5% customers who have previously set a preference for the old editor will be directed to the new workflow editor by default when they try to edit their workflows.

• The UI will continue to have the option to edit the workflow in the the old experience. But when re-entering the workflow editor, admins will be be directed to the new workflow editor each time so that they can familiarise themselves.

If you’ve not used the new workflow editor in a while

Jira admins can expect the following in the new workflow editor which makes the experience even more powerful and streamlines:

✨ Some recent improvements: Allowing same name transitions and fixed some bugs including ordering of actions on transitions.

✨ A text view: For the most complex workflows, the new workflow editor is now equipped with a text view for workflow editing.

✨ Modern and fast editing experience: Consolidated, easy-to-use, visually modern interface – no more navigating across multiple tabs with the ability to publish modifications immediately.

✨A lowered learning curve: Designed to be more approachable for new admins, with less technical jargon, more in-context help and Rovo skills to edit your workflows with AI.

…and so much more!

Got feedback?

As always, we welcome your feedback. If you see ways to improve the new editor or face blockers transitioning from the old one, please raise a support ticket here, or reach out to us directly via the feedback button in the bottom left of the new workflow editor. Ensure you select “Atlassian teams can contact me to learn about my experiences to improve Atlassian apps and services” so we can follow up.

FAQs

Q: When will I see these changes on my site?

New workflow editor will become the default workflow editing experience for all customers in March 2026. We'll start removing the old workflow editor from June 2026.

Q: Can I still access the old workflow editor?

Yes. If you are a Jira admin you will be taken to new workflow editor by default when editing a workflow. You can use the three dot menu on the top right to switch to the old editor temporarily to continue editing your current workflow which is available till June 2026.

 Q: Will I need to “migrate” my workflows from the old editor to the new editor?

No. Today, you can update your workflows in both the old and new workflow editors. Once the old editor is removed, you will be able to update your workflows in the new editor.

[Yatish Madhav]

Thanks @Swarna Mehta - looking forward to getting rid of the old experience :)

Quick question regarding performance, i know this is only a front end experience of the editor for workflows, but would this change and removing the codebase and the ability to use the old editor affect overall Jira performance for end users, even if it is by miliseconds?

Thanks

Yatish

[Bartłomiej Borowy]

Hi @Swarna Mehta

I have a question about the configuration options for validators in the old model vs. the new one you are implementing.

In the old model, we can set up validation so that a specific transition appears (or does not appear) for a specific field value—for example, “Request Type.”

In the old flow, we have the option of conditioning (= / < / > / != and others) for specific fields and comparison type settings (String, Number, Date with time, Date without time, and Option ID).

When I verify this on the new standard, the transition is indeed configured, but when I go to its configuration, I can choose between text or a number.

How will the new flow be adapted to these differences between the two flow creation models?

In my opinion, implementing the new flow and forcing administrators to switch to it without adopting a 1:1 solution will significantly worsen the work on flows in projects.

For comparison purposes, I am adding a few screenshots to better illustrate my question.

[Savannah Ehrhardt]

I have many workflows that use universal transitions (Any Status -> Itself). I know you can't create those in the new editor (please add that ability), but will you still be able to edit existing ones after the old editor goes away?

I use those heavily for integrations with other systems. For example, the Zendesk integration provides a post function that sends a comment or status change to Zendesk. It's great to be able to use that from any Jira status in combination with an automation, without having to recreate the transition for each status.

[Darren Grant]

Hi @Bartłomiej Borowy 

The support for comparing the request type field by option ID in the restrict to when a field is a specific value rule is a gap that we are aware of and actively working on addressing - JRACLOUD-97331. This will be addressed when the default editor is changed in March.

This rule in the old editor allowed combinations of fields types and comparison types that made no sense. Like comparing a text field by option ID. In the new editor we are attempting to only provide combinations that make sense in the UI, but in this case we missed one.

If admins come across a situation like this of a capability from the old editor that is not available in the new editor, please raise a ticket with support. They will be able to guide you as to where to find it in the new editor, or we can identify it as a gap and work to address it before the old editor is sunset from June 2026.

Thanks for raising this.

[Darren Grant]

Hi @Savannah Ehrhardt 

You can absolutely create looped transitions that are available to any status (any -> itself) in the the new editor.

If you have any related issues creating these in the new editor, please let us know.

[Darren Grant]

Hi @Yatish Madhav 

The area where workflows impact end user performance most is in transitions. For instance evaluating conditions to determine which transitions are available on a work item, or executing validators and actions when a transition is performed.

Sunsetting the old editor is mainly targeted at the editing experience, but it does open doors for additional improvements down the track. Like introducing more powerful rules so that admins don't have to configure many individual rules on a transition to achieve their use case. Having fewer rules on a transition does improve evaluation performance.

I hope that answers your question.