New Workflow Editor: 40 old names, 20 rules, 4 verbs. The complete rules map.

[Sami Shaik]

As of July 26, the old workflow editor is gone. If you built years of muscle memory on conditions, validators, and post functions, here is the good news: nothing was removed from the engine. Roughly forty legacy rule names were consolidated into twenty rules under four verbs, in one panel. And while checking the list against a live instance this week, I found something better than a consolidation: one of the twenty is brand new. More on that below. (For what to check right after the removal, including orphaned drafts, see my previous post.)

Scope note: Jira Cloud, company-managed projects, global workflows. Data Center keeps its own editor. Team-managed projects use a separate, simpler rule system. Everything below was verified against a live Cloud instance on 27 July 2026; Marketplace and Forge apps add their own rules to these lists, which I have left out.

The four questions every transition asks

Select any transition and its Rules panel answers four plain questions, in this order:

1. Who is allowed to use this transition? That is Restrict transition (the old conditions). The panel says it plainly: hide this transition when these aren't met.
2. What does the person fill in? That is Request input (the old screen configuration).
3. What must be true before it completes? That is Validate details (the old validators). If a check fails, the work item stays put and nothing below runs.
4. What happens automatically after? That is Perform actions (the old post functions).

New admins can stop here and already read every workflow on the site. The rest is the full catalogue behind each verb, exactly as it appears in the product today. Triggers and Properties sit in the same panel as their own sections, so the entire behaviour of a transition finally lives in one place.

Restrict transition: 7 rules (was 17 condition names)

Restrict who can move a work item. Limit the transition to specific people: roles, groups, permission holders, the assignee, or the reporter. This single rule absorbed nine legacy conditions (Only Assignee, Only Reporter, Permission Condition, and the whole User Is In Group / Project Role / Custom Field family).

Restrict to when a field is a specific value. The transition only appears when a field holds the value you define. Absorbs Value Field and Compare Number Custom Field.

Restrict to when a work item has been through a specific status. Only available once the item has visited a given status. Was Previous Status Condition.

Restrict users who have previously updated a work item's status. Whoever moved it last cannot move it again. Your four-eyes control. Was the Separation of Duties condition.

Restrict based on the status of subtasks. The parent cannot move until its subtasks are in the right state. Was Sub-Task Blocking Condition.

Block transition until approval. No approval, no move. Pairs with JSM approval steps.

Restrict from all users. Hides the transition from every person. The classic use: moves that only automation should ever fire. Absorbs Hide From User and Always False.

Request input: 1 rule (was screen configuration)

Show a screen. Pick the screen, and with it the fields the person is asked to complete during the move. The natural partner of every validation below: request the input here, enforce it next.

Validate details: 6 rules (was 12 validator names)

Validate a field. The workhorse. Required fields, changed-during-transition checks, single-value checks, date comparisons, date windows, and regex checks all live under this one rule.

Require a work item to have a form attached and Require form submission on a work item. The two form gates.

Validate that parent work items are in a specific status. The mirror of the subtask restriction, pointed upward.

Validate that people have a specific permission. The person completing the move must hold a given permission. The old User Permission Validator is formally sunsetted; this rule replaces it.

Validate that a work item has been through a specific status. History check at completion time.

Perform actions: 6 rules (was 10 post function names, plus one that is entirely new)

Update a work item's field. Set or clear any field. Absorbs Update Issue Field, Update Issue Custom Field, and Clear Field Value. The rule behind the classic hygiene pattern: clear the resolution when something reopens.

Assign a work item. Hand it to the current user, the reporter, or whoever the flow demands. Absorbs the Assign To family, and note that the legacy Update Issue Field rule maps here too when it targeted the assignee field.

Copy the value of one field to another. Field-to-field copy at transition time.

Set a work item's security level. Apply a security level as part of the move.

Trigger webhook. Call an external system when the transition completes. The traditional bridge out of Jira.

Trigger agent action. And here is the one with no legacy ancestor: a transition can now invoke a Rovo agent natively. As I write this, the official rule mapping table does not list it; it is simply there in the product. Think about what that unlocks: a work item hits Done and an agent drafts the release note. An incident closes and an agent summarizes the timeline into the postmortem page. The old editor could only update fields and call webhooks; the new one can hand work to an agent. This is the quiet headline of the whole transition, and it points at where workflows are going: deterministic rules deciding when, agents doing the writing.

Transition reuse is now multi-From

The old ritual of building one transition and reusing it across statuses is now just a property: a transition has multiple From statuses. One set of rules, drawn once. If your old workflows leaned on near-identical reused transitions with slightly different rules, verify your three most complex workflows read the way you expect.

Four patterns, with the real rule names

The approval gate. Restrict who can move a work item (approver role) plus Validate a field (the approval evidence). Most teams configure only one of the two and wonder why the gate leaks.

Evidence on close. Show a screen (resolution, root cause) plus Validate a field (required). Nobody closes without saying why.

Least privilege. Restrict who can move a work item so only QA reaches Done. Transitions people cannot use do not appear for them.

Hygiene on reopen. Update a work item's field to clear the resolution, Assign a work item back to the reporter. The workflow cleans up after itself.

The honest notes

Docs lag the product: the official support page still carried instructions for opening the old editor days after the old editor stopped existing, and its rule table is one rule short of what the product shows. Trust the Rules panel in front of you over any page, including this one. App-provided rules from Marketplace and Forge apps appear in the same lists,  open each one once and confirm it renders its configuration and a readable description. And XML export went with the old editor: machine-readable workflow copies are JSON now, via the Bulk get workflows API.

The checklist

• Learn the four questions; they read every workflow on the site
• Find each legacy rule you actually use in the catalogue above and open its new home once
• Try Trigger agent action on a low-stakes transition before you design around it
• Verify multi-From transitions consolidated with the rule sets you expect
• Rebuild approval gates as restrict plus validate, never one without the other
• Open every app-provided rule once and confirm it renders and describes itself
• Snapshot complex workflows as JSON via the Bulk get workflows API

Forty names becoming twenty rules is the rare consolidation that makes a system easier to teach. The twentieth rule is the reason to pay attention: the workflow engine just learned to delegate.

Sources: Rules verified in the Rules panel of a live Jira Cloud instance, 27 July 2026. Rule mapping cross-checked against Atlassian support, "What is the new workflow editor." Old editor removal dates per the official deprecation notice on this Community

[zoltanersek _outpostlabs_dev_]

Thanks, The Trigger agent action rule definitely stood out to me as well. It'll be interesting to see how teams balance deterministic workflow logic with AI-powered actions as that capability matures.

[Yatish Madhav]

Thanks @Sami Shaik - This is a great post detailing old vs new. I think Atlassian should post things like this when making changes big or small for further transparency. It also eliminates ambiguity!

I really like the new editor and the simplification of it. 'Trigger agent action' seems great but I think once we are able to enable and use Rovo, it may reveal more of its usefulness.

Thanks again