Summary

In the automation rule branches provide the flexibility to iterate through a set of issues or the individual elements of an object through smart branching. While they can be very useful and provide help to build powerful automation rules, yet by design they can become a bottleneck in a complex automation rule that relies on the outcome of branching operation in the subsequent actions of the rule. 

Environment

Jira service management cloud.

Diagnosis

In some cases it was observed that the immediately subsequent actions after the branch are executed without a valid output from the branch operation. This is more significant if the next immediate action was an IF condition relying on the output from the previous branch operation.

Cause

This happens because the branches operate in parallel to the rule's main execution thread. This means if a branch is operating on a large set of issues then it might take some time to finish. If the subsequent actions after the branch rely on the outcome of the branch operation then they might not be able to get the right data because while the branching operation was in progress the main execution thread would continue to execute the actions after the branch.

Solution

One reliable solution or workaround to this problem is to break the rule into two rules and chain them together such that until the first part of the rule (possibly containing a branch) finishes completely, the remaining logic contained in the second rule (which relies on the outcome of the first rule) does not start executing.

An example case:

Let's say you are sending a web request and you want to compare an issue field value against the data set returned in the webhook response. If the issue field value condition matches against an issue returned in the web book response you want to perform certain actions subsequently. If you put all the subsequent actions after the branch in the same rule then you might run the risk of failing the comparison because by the time branch finishes execution, the main rule thread might have already begun executing subsequent actions without waiting for the branch information processing all data. To avoid this you can take the following approach.

Break the rules into two separate automation rules.

• In the first rule, send a web request and perform the issue field value comparison against the data returned in the webhook response.
• Based on the result of the comparison, save the result in a custom field to be used later in the second rule. This custom field will work as a flag to indicate whether the comparison was successful or not. You can set any trigger suitable for your needs for the rule to be triggered.

• In the second rule, the trigger must be when the field value changes and the field you monitor should be the one that was used for the result of comparison in the first rule.
• In the rule details, the check box titled Check to allow other rule actions to trigger this rule. Only enable this if you need this rule to execute in response to another rule must be checked in order to allow this rule to be triggered by the first rule when the comparison result is saved in the custom field.

• The similar approach can be adopted in the case when the rule reaches its threshold of the maximum number of components allowed in one rule. See: Automation service limits