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 action applies actions to related issues, for example, transitions all sub-tasks.
Related issues condition checks the state of related issues, for example, if all linked issues are closed.
To work with an issue in another project the rule must be able to execute in the projects the issues are in by being either a multiple 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 the 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}} point to the related issue, not the trigger issue.
Note: You can still reference the the trigger issue using {{triggerIssue}} instead.
You also have the option to process these issues in bulk.
Branching is useful in a number of cases, such as:
- Syncing all sub-tasks by copying a value from the parent to field X
- 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.
- Branches on single issues are run inline (for performance). Therefore the main branch will not continue execution until the sub-branch completes.
Accessing created issues
Automation rules can create issues with create issue or clone issue. Performing further actions (e.g. adding a comment, creating sub-tasks) on newly created issues in the same rule requires a related issue branch.
This is because the main rule execution branch of an automation rule always applies rules to the trigger issue, not the created issue. For example, adding a comment issue action after a create issue action in a rule, adds the comment to the trigger issue, not the created issue.
Here's an example rule to solve this problem:
You can also select the 'Most recently created' issue in the Related Issues condition if that's the only one you need to action.
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.
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
Select the related issue type:
Sub-tasks
Parent
Stories (or other issues in this Epic)
Epic
Created issues
Linked issues
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
Select Save.