Advanced automation components
Advanced automation components are available only on the Premium and Enterprise plans.
Advanced components help you manage work that has multiple paths, timing, or repetitions in a single rule. By adding advanced components to your automation rule, you can:
Eliminate manual workarounds: Manage multi-component, multi-team processes in one rule, instead of relying on multiple rules that depend on each other.
Boost efficiency: Automate parallel and conditional work to reduce errors and save your team's time.
Enterprise-grade advanced control: Get clear visibility and easily scale automation across your organization.
Once you’ve added an advanced component to your rule, all components will be wrapped in a rule group. More on rule groups
Branch with conditions
This component is only available in Jira and Jira Service Management Premium and Enterprise plans.
Use smart values here: Yes
This component allows you to split your rule into different paths based on conditions that you set. Each path represents one scenario that can happen when the rule runs. Use this component when a single trigger must lead to different outcomes based on its context.
When the rule runs, each branch will be examined in the order you set them up. As soon as it finds a branch where all conditions are true, it runs the actions in that branch.
Note: Although more than one branch’s conditions can be true for the same rule run, Branch with conditions always runs only the first matching branch. It is recommended to order your branches so the preferred scenario appears first.
A Branch with conditions component includes up to three branches, where each branch has:
A name
One or more conditions
The actions to run when those conditions are true
You can also add an optional Fallback branch that runs if no other branch matches your conditions.
In the following example, the rule uses a branch with conditions component to take any of three paths when a work item is created, based on the work item’s priority: Highest, High, or a Fallback path when neither condition is met.
Branch with conditions
This component is only available in Jira and Jira Service Management Premium and Enterprise plans.
Use smart values here: Yes
This component allows you to split your rule into different paths based on conditions that you set. Each path represents one scenario that can happen when the rule runs. Use this component when a single trigger must lead to different outcomes based on its context.
When the rule runs, each branch will be examined in the order you set them up. As soon as it finds a branch where all conditions are true, it runs the actions in that branch.
Note: Although more than one branch’s conditions can be true for the same rule run, Branch with conditions always runs only the first matching branch. It is recommended to order your branches so the preferred scenario appears first.
A Branch with conditions component includes:
Up to three branches, where each branch has:
A name
One or more conditions
The actions to run when those conditions are true
You can also add an optional Fallback branch that runs if no other branch matches your conditions.
In the following example, the rule uses a Branch with conditions component to take any three paths when a work item is created, based on the work item’s priority: Highest, High, or a Fallback path when neither condition is met.
Delay until
This component is only available in Jira and Jira Service Management Premium and Enterprise plans.
Use smart values here: No
This component lets you delay when the branch runs its components. You can either pause the branch for a set amount of time or wait for a specific event before the branch continues. Each delay can be between 10 seconds and 90 days.
You must add this component before a condition or action. It only delays the branch’s components and does not affect the rest of the rule.
When “Delay until” is before an action, the rule pauses until the delay ends.
When “Delay until” is before a condition, the rule pauses for the delay, then evaluates the condition.
Supported events:
Work item updated
Alert updated
Incoming webhook More on how to verify incoming webhook trigger
In the following example, when a work item is created, the rule waits nine minutes before adding a comment to the ticket.
Loop
This component is only available in Jira, Confluence, and Jira Service Management Premium and Enterprise plans.
Use smart values here: Yes
This component lets you run the same group of actions several times in a row. Each time the rule runs, the loop checks the conditions again and only repeats its actions up to three times if the conditions are still true. Use this component when you need to repeat the same action under specific conditions, rather than creating multiple separate rules.
You can add up to 32 conditions that control whether the loop continues or stops. At the start of every loop iteration, automation checks these conditions. If the conditions aren’t met, the loop ends. Loop conditions only evaluate information from the trigger and don’t support conditions based on state variables (values that are stored and updated while the rule runs).
Select Run components once before first loop to run the components inside the loop one time before automation checks any loop conditions for the first iteration.
Loop inputs
Loop inputs let you define values that the loop can read and use in its conditions.
An input consists of:
A variable name
A value
You can set the value of a loop input using:
Smart values from the trigger context
Output references produced by rule groups, as long as those rule groups are executed before the loop or inside the loop
Loop conditions can only use data from the trigger context and the loop inputs you’ve defined. They don’t evaluate rule group outputs directly unless those outputs are passed into the loop as input variables.
Loop variables
The loop exposes two state variables you can reference in other components:
loop.count- Number of iterations executed by the loop component.loop.conditionMet- Whether the loop’s conditions evaluated to true. Returnstrueorfalseas a string.
These values are stored in the loop’s internal state and are updated only when the loop completes execution.
To use these variables in subsequent components, add them as inputs to the component or group where they are needed.
Nesting
Nesting allows you to put one advanced component within another in a rule. Loops can’t be nested within themselves. However, you can combine it with Branch at the same time and Delay until components.
Each rule can have a maximum of two nesting levels. Both Loop and Branch at the same time count toward these nesting levels. This means you can have:
A Branch at the same time inside a Loop (with or without Delay until)
A Loop inside a Branch at the same time (with or without Delay until)
A Branch at the same time inside another Branch at the same time (with or without Delay until)
In the following example, when a work item is created, the rule uses a Loop component to add the same comment up to three times. Before the loop repeats, the loop checks whether the work item’s Status is still “Blocked.” As soon as the status changes, the loop stops, and no more comments are added.
Was this helpful?