What is the new workflow editor?
The workflow editor allows admins to define, customize, and manage how work items move through various stages of work. It visualizes the flow of work, allowing you to add statuses, transitions and rules to define operations or conditions in the flow.
You can use the workflow editor to automate routine actions, apply business rules, and configure different work item paths based on project or work type requirements.
What’s changed in the new editor
The new workflow editor has all the same actions as the old experience, but it’s now in one place. From a single view, you can configure statuses, transitions, and transition rules without having to navigate around Jira, or multiple tabs.
Toolbar: Add statuses, transitions, and rules to create your workflow.
Update or discard: Publish your changes instantly. If you’re not happy with your changes, you can always throw them away and return to your original workflow.
Details: Select a status or transition from the diagram and edit its name, rules, properties, and more.
Diagram: Drag to move statuses and create transitions. Select a status or transition to see its details.
Relevant projects: See which projects use the workflow before you publish.
Key differences
Edit and publish instantly
A key difference with the new editor is that it doesn’t use draft workflows.
In the old editor, changes were made across multiple pages and stored in a draft until you were ready to publish. In the new editor, admins only ever edit the published workflow. Changes are now all made in the same view and can be published by selecting Update workflow, or discarded.
A big benefit of this is that the new editor doesn’t have the same limitations around active workflows as the old editor.
This means:
you can delete statuses in active workflows, and
if a status has no outgoing transitions (not including global transitions), new outgoing transitions can be added (regular or global).
You no longer need to copy the workflow, make changes, and then update the workflow schemes to activate it. It’s all one editing experience.
Delete statuses and update work items
When you delete a status in your workflow, you’ll immediately be taken through steps to move work items from that deleted status to a new status.
Know which projects use your workflow
Before you publish your workflow, you want to make sure you’re updating the right projects, and now, you can do it right from the workflow editor itself.
Share transitions as you create
In the new editor, you can create transitions for work items in multiple statuses with a single set of rules and properties.
In the old editor, you could do this by creating a transition between two existing transitions, then applying that transition to other statues via Add transition, then Reuse transition.
In the new editor, you can apply a transition to multiple statuses by selecting multiple From statuses when you create the transition or edit an existing status.
Easily add rules to a transition
Rules is where you’ll find conditions, validators, and post-functions, with updated terminology (restrict, validate, and perform action). These operations created while using the old editor should be retained when moving to the new editor.
These are the new workflow editor’s rules:
Conditions → Restrict transition
Validators → Validate details
Post-functions → Perform actions
The new editor's rules provide the same conditions, validators, and post-functions as the old editor, they’ve just been combined and renamed.
Use these rules to limit when your team can use a transition, or to automatically perform an action as they do.
This table shows how rules map between the old editor and the new editor.
Old editor | New editor |
---|---|
Conditions | |
Only Assignee Condition | Restrict who can move a work item |
Only Reporter Condition | |
Permission Condition | |
User Is In Group | |
User Is In Any Group | |
User Is In Project Role | |
User Is In Any Project Role | |
User Is In Custom field | |
User Is In Group Custom Field | |
Value Field | Restrict to when a field is a specific value |
Compare Number Custom Field | |
Previous Status Condition | Restrict to when a work item has been through a specific status |
Separation of Duties condition | Restrict users who have previously updated a work item’s status |
Sub-Task Blocking Condition | Restrict based on the status of subtasks |
Block transition until approval | Block transition until approval |
Hide From User Condition | Restrict from all users |
Always False Condition | |
Validators (and screen configuration) | |
Field Required Validator | Validate a field |
Field has been modified Validator | |
Field has single value Validator | |
Date Compare Validator | |
Date Window Validator | |
Regular Expression Check | |
Forms: Forms attached | Require a work item to have a form attached |
Forms: Forms submitted | Require form submission on a work item |
Parent Status Validator | Validate that parent work items are in a specific status |
Permission Validator | Validate that people have a specific permission |
Previous State Validator | Validate that a work item has been through a specific status |
User Permission Validator | Sunsetted. Use the Validate that people have a specific permission rule. |
Screen field (in transition details) | Show a screen |
Post-functions | |
Update Issue Field | Update a work item’s field |
Update Issue Custom Field | |
Clear Field Value | |
Assign to Current User | Assign a work item |
Assign to Lead Developer | |
Assign to Reporter | |
Update Issue Field (for assignee field) | |
Copy Value From Other Field | Copy the value of one field to another |
Set issue security level based on user's project role | Set a work item’s security level |
Trigger a Webhook | Trigger a webhook |
Want to learn about the old editor? Read how to manage workflows in the old editor.
Was this helpful?