Automation concepts – Workarounds for Nested Branching

[#1]

Estimated time to read: 6 minutes

TL;DR: Simple rules (without advanced component features) do not support nested branching features yet. There are several possible workarounds, depending upon your specific scenario needs. Let's describe (but not implement) some workarounds, allowing you to consider them for further experimentation.

Why do this?

A quick read of community posts provides several scenarios where it may be valuable to nest branches; that is, to contain one-or-more branches inside of another branch. Some of these include:

• GIVEN two multiple-select options fields WHEN a work item is created THEN iterate over each field to create paired-value, child work items
• GIVEN a multiple-select options field WHEN I iterate over the selected values THEN conditionally perform some actions based upon a different field
• GIVEN two multiple-select options fields WHEN sending an email with dynamic content as a table THEN iterate over each field to build the content
• etc.

Some community-provided scenarios can be solved with workarounds, while others cannot...or cannot easily be solved. Let's quickly outline some options to consider what might be involved in workarounds.

A list of workarounds

How	Rule Complexity	Risks
List Iteration / Filtering Rather than using branching for reporting scenarios, use long-format list iteration and / or list filtering with conditional logic for the custom field options to make content, such as in an email.	Medium	Low
Merged Variables Use created variables and inline iteration functions to create a single variable which contains all the combinations as a delimited list; then split that variable into a list and use a single advanced branch to iterate and process each.	High	Medium
Outer IF / ELSE block Use an IF / ELSE block at the outer, top rule level and check each value for one of the custom fields. Then inside of each condition result, advanced branch over the values in the second field. This works because branches can be inside an IF / ELSE block, but the opposite is not supported.	Low	Medium
Multiple Rules Use an advanced branch over one of the custom fields, and then use the Send Web Request action to trigger as second rule with an Incoming Webhook Trigger, passing the work item key and first field's value; the second rule will iterate over the second custom field, such as to create the work items, etc.	Medium	High
Select List, Cascading Field Remove the two custom fields and replace them with a cascading field, and advanced branch over the parent / child values of that field.  This may require joining the parent and child values to make both available to the branch.	Low	Low
External Service Create an external service which can perform nested branching to perform your actions with the REST API endpoints, and call your service with Send Web Request action.	Medium	Unknown

There is a lot of variation in the possible workarounds, from replacing the fields to building your own external solution. I included my interpretation of the automation complexity and risks involved in such solutions.

For example, Outer IF / ELSE block could be tried immediately with basic rule knowledge / experience, but has increased risks due to the likely duplication of rule actions within each condition block. Contrast that to an External Service, which may be easy or difficult to build, subject to the capabilities and resources of your own team, making the risks unknown for this article.

Here is a quick inventory of potential risks for these workarounds, helping you ponder what may be encountered:

1. By their nature, rules to workaround nesting gaps are more difficult to explain to others, and thus more difficult to maintain
2. Hardcoding option / list values (e.g., in conditions) could cause rule maintenance challenges / risks
3. There are known defects with some field access in long-format iterators (e.g., when using date functions)
4. With multiple rules chained together, when there is an Atlassian automation outage, it is unclear if / how such chained rules will perform
5. Switching from two, custom option fields to a single cascading one may confuse people and lead to additional Jira configuration work
6. Additional risks, based on the purpose of your fields and how they are used today

Wrapping it up

As with all things automation related, I suggest pausing to understand the problem you are trying to solve, considering if automation is even a good / better approach for doing so...and then experimenting in a safe and deliberate manner as you proceed toward a solution.

Unlike my other articles, this one is intended to point people in experiment directions rather than provide a turnkey solution. That seemed prudent as even simple approaches may be challenging for scenarios which require nested branching.

Please let me know your feedback on this article, your additional ideas for the topic, and as always...

Happy rule writing!