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.

Screenshot of an automation rule where a “Work item created” trigger runs two actions: add a comment and send an email.

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.

Screenshot of an automation rule where a “Work item created” trigger runs three actions based on the work item’s priority.

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:

In the following example, when a work item is created, the rule waits nine minutes before adding a comment to the ticket.

Screenshot of an automation rule where “Work item created” trigger waits 9 minutes before adding a comment.

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. Returns true or false as 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:

  • Branch at the same time inside a Loop (with or without Delay until)

  • Loop inside a Branch at the same time (with or without Delay until)

  • 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.

Screenshot of an automation rule where “Work item created” trigger can comment 3 times until a condition is met.

Still need help?

The Atlassian Community is here for you.