In the real world, a Jira issue rarely exists in isolation. Issues can be interconnected in many ways:

• Issue Links (relates to, blocks, duplicates)
• Parent -> Sub-tasks
• Epic -> Stories
• Similar field values
• ...and many more!

When these combine it can create a confusing hierarchy of issues that can be daunting to deal with. Fortunately we have 2 ways that make it easy to work with related issues:

• Related issues condition - To check the state of the related issues. E.g. are all linked issues closed?
• Branch rule action - Apply actions to related issues. E.g. transition all sub-tasks.

Used together, these can create very powerful rules that can traverse complex issue relationships. For example, when all sub-tasks are resolved, transition the parent issue.

Related issues condition

With Automation for Jira's Related issues condition, you can check the state of relationships before progressing a rule.

We provide a handful of built-in relationships: sub-tasks, parent, epic, stories, linked issues, issues in sprint/version. Alternatively, if the relationship can be described in terms of JQL, we also allow you to do this.

Once you have chosen your relationship, you then have the choice of testing whether an issue with that relationship exists or not, whether some of the issues match a given JQL query or all issues match.

This allows for a massive range of use-cases, including:

• Does this issue have any linked issues of type X?
• Only proceed if the issue has a parent or Epic
• Are any of the issues in a sprint/version unassigned?
• Are all stories in this epic resolved?
• Check that Sub-tasks of type "QA" that are resolved have a value set for "Testing notes"...
  
  

Branching on related issues

It is also possible to perform actions against related issues - this is referred to as "Branching". This is in reference to the rule no longer executing in a linear fashion but it expands out in 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.

Some example use-cases of when branching is useful are:

• Sync all sub-tasks by copying a value from the parent to field X
• Move an Epic into "In progress" when a Story is moved to "In Progress"
• Comment on "is blocked by" linked issues when an issue is resolved.
  
  

Ordering of branch executions

Branches on multiple issues (E.g. 4 sub-tasks) will run in parallel with no guarantee one will finish executing before the next one starts. Therefore you can not rely on changes between branches.

Branches on multiple issues are run as a new process, with the main branch continuing execution straight away (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 on current?

This branches the rule and performs subsequent conditions and actions on the current issue and continues actions below. Useful when comparing an issue against multiple values and a different action is needed for each.
Our new If/else condition has made this option near redundant.

Accessing the trigger issue

You can't edit the trigger issue with values from a related issue, but you can access the trigger issue with the {{triggerIssue}} smart value. It works exactly the same as {{issue}} and gives read-only access to all of the trigger issue's fields whilst {{issue}} accesses the related issue.

Example: Sync parent & sub-tasks

A great example for this is, when a parent issue moves to Done it's usually desirable to also move its sub-tasks to Done (read this blog post that talks about all the awesome things you can do with branching a separate rule chain for related issues).

In this rule, you can see how to synchronize parent and sub-tasks: