Branch automation rules to perform actions on related issues

Issues rarely exist in isolation. They often contain sub-tasks, are stories that are part of a larger epic, or are simply linked to other issues using certain relationships. This means that when using automation, actions often need to apply, not only to the source issue that triggered the rule but also to any issues that are related to the source issue.

Special conditions and actions are available to create powerful rules that can work across complex issue relationships. For example, checking that all sub-tasks of a parent issue are resolved.

• Branch rule applies actions to related issues, for example, transitions all sub-tasks.

• The Related issues condition checks the state of related issues, for example, if all linked issues are closed.

In order for a rule to work with an issue in another project, it must be able to execute in the projects the issue is in, either being a multi-project or global rule.

Branching on related issues

When configuring automation rules, it's possible to perform actions against related issues – this is referred to as branching. This is in reference to the rule no long executing in a linear fashion, but instead expanding out to multiple paths.

When a rule is branched on an issue or list of issues, the sub-branch of the rule is executed against each issue. All actions and references to {{issue}} will point to the related issue, not the trigger issue.

Branching is useful for a number of use cases, such as:

• Synching all sub-tasks by copying a value from the parent to a specific field.

• Moving an Epic into In progress when a Story is moved to In progress.

• Commenting on is blocked by linked issues when an issue is resolved.

Ordering of branch executions

• Branches on multiple issues (such as 4 sub-tasks) will run in parallel with no guarantee one will finish before the next one starts. Therefore, you cannot rely on changes between branches.

• Branches on multiple issues are run as a new process, with the main branch continuing execution before the sub-branch starts.

Accessing created issues

Rules can create issues using the Create issue and Clone issue actions. Performing further actions, such as adding a comment or creating sub-tasks, on these newly created issues within the same rule requires a related issue branch.

This is because the main branch of a rule always applies to the trigger issue, not the created issue. For example, adding a Comment on issue action after a Create issue action adds a comment to the trigger issue, not the created issue.

To address this, create a new branch for All created issues to allow you to action newly created issues.

Alternatively, you can use the Related issues condition (Most recently created) if you the only need to action a single issue.

Branching restrictions

• Nesting: Branches cannot be nested in one another, and do not support the use of the If/else block condition.

• Isolation: Branches are isolated. Any changes that occur in a branch will not be visible to the main branch, or any others. For example, if a branch has a Create variable action, the created smart value can be used in that same branch, but can't be used in the main branch, nor in any other the other branches.

Related issues condition

The Related issues condition checks the state of related issues before progressing a rule.

This condition allows for a vast range of use cases, including checking:

• Whether or not an issue has linked issues of a specific type.

• If the issue has a parent or Epic.

• If any of the issues in a sprint/version are unassigned.

• If all the stories in the Epic are resolved.

• That resolved sub-tasks of a specific type have a specific value set.

Setting up the Related issues conditions

1. Select the related issue type:

   • Sub-tasks

   • Parent

   • Stories (or other issues in this Epic)

   • Epic

   • Created issues

   • Linked issues

2. Select the condition to check if related issues:

   • Are present

   • Are not present

   • All match specified JQL

   • None match specified JQL

   • Some match specified JQL

3. Select Save.

Learn more

Check out how we use related issues in our Jira automation template library.