How to Execute Branches in Parallel and Maintain Order?

[Mariano Tallarico _Appricity_]

Hello community, greetings to everyone.

I wanted to share a case I’ve been working on and ask if anyone has successfully resolved something similar.

We were requested to implement an enhancement to a previous setup, where the technical challenge was to process an array obtained from a JQL query in a specific order. The solution had to adhere to the premise of minimizing the number of automation executions, avoiding the use of webhooks or unnecessary loops.

We tested two main approaches:

1. Creating a branch with an ordered JQL query.
2. Using a "For Each" loop to iterate over the array obtained from Lookup Issues.

Both alternatives encountered the same key issue: Jira Automation branches execute in parallel, resulting in random orders instead of maintaining the original sequence. Here are the details and results for each approach:

---

Alternative 1: Branch with JQL

• Trigger: Manual (for testing purposes).
• Branch: Executes a JQL query that returns issues in alphabetical order (e.g., ABC-1, ABC-2, ABC-3).
• Action: Log the keys ({{issue.key}}).

Result:
Even though the JQL query returns an ordered array, the branch executes in parallel, resulting in random orders such as:

• ABC-3, ABC-1, ABC-2
• ABC-2, ABC-3, ABC-1
• ABC-1, ABC-3, ABC-2

---

Alternative 2: For Each with Lookup Issues

• Trigger: Manual (for testing purposes).
• Lookup Issues: Retrieves issues in alphabetical order (e.g., ABC-1, ABC-2, ABC-3).
• Branch: "For Each" loop over the keys ({{lookupIssues.key}}), with a logging action.

Result:
Similar to the previous case, the branch executes in parallel, resulting in random orders such as:

• ABC-3, ABC-1, ABC-2
• ABC-2, ABC-3, ABC-1
• ABC-1, ABC-3, ABC-2

---

Conclusion:
We confirmed that Jira Automation branches execute in parallel, which makes it challenging to achieve the required serial order for this case.

---

Question for the community:
Do you know of any way to make a branch execute sequentially in Jira Automation? Or have you discovered creative solutions or alternatives to address similar needs?

Greetings, Mariano

[Bill Sheboy]

Sticking with the original thread to preserve the flow, as there may be other suggested solution approaches / responses the community provides...

As a disclaimer, I am just another Jira customer and have no internal knowledge if a reduced number of items for a serial versus parallel would be easier, although it is likely if Atlassian builds this it will adhere to the existing 100 issue limit.  Again, I look forward to see what the Atlassian team releases for that suggestion I linked to.

You note a cloning scenario for multiple levels and a large number of issues.  There are many community posts about this need, and two common recommendations (other than webhooks or import from CSV) are:

1. investigate marketplace apps which specifically handle complex cloning scenarios
2. use multiple rules, one for each level in the issue hierarchy, to perform the cloning

The first has cost implications and the second has complexity, ordering, and risk ones.

[Mariano Tallarico _Appricity_]

Hi  , @Bill Sheboy 
First of all, thank you for your response.

I’ll keep your recommendation in mind about posting as a question instead of a discussion in future threads.

I understand that for Atlassian, releasing an update of this magnitude could significantly increase the number of executions. However, wouldn’t it be possible to limit this (just my humble opinion) by controlling the number of components, similar to how it’s done with items and conditions today? Or is there a technical or design aspect I might be overlooking? I’m open to learning from other perspectives in the community.

Regarding my use case: I tried multiple approaches, including using JQL with ORDER BY, which seemed like the logical solution. However, all attempts resulted in parallel execution of the Branches, which does not fulfill my requirement.

To provide context, I was working on a scenario where I needed to clone the entire structure of an epic (using it as a template) and replicate it into other epics based on certain parameters. While cloning tasks and subtasks is already challenging (as discussed in the community), I managed to solve that part. What remained was ensuring that the cloned tasks retained the same order as in the original epic. For example, if the original epic had tasks ABC-1, ABC-2, and ABC-3, the cloned epic should maintain that same order.

While it’s possible to achieve this through loops and Webhook calls, our estimates showed that this approach would result in approximately 100 executions for each epic structure cloned (as there are around 100 issues between tasks and subtasks, requiring a call and response for each).

In the end, the workaround I implemented was to save the key of the original issue into the cloned issue. Then, using filters, I sorted the cloned issues based on this field.

Greetings. Mariano

[Bill Sheboy]

Hi @Mariano Tallarico _Appricity_ 

First thing, as you are asking a question I recommend posting it that way rather than as a discussion topic.  It is more likely to get community visibility and suggestions that way.

There is an old suggestion to allow better control (or disabling) of the parallel / asynchronously processing for automation rule branches which could be on more than one thing: https://jira.atlassian.com/browse/AUTO-32

That one finally appears to be in progress, although it is unclear what Atlassian will implement for this need.  Adding the ability to process branches sequentially may lead to many more rules exceeding some of the service limits...halting rule execution for an entire site for 12 hours up until the remainder of the entire month!

Given the criteria you have listed, there is no possible solution with the built-in automation rules at this time:

The solution had to adhere to the premise of minimizing the number of automation executions, avoiding the use of webhooks or unnecessary loops.

As you note, built-in rule solution approaches include:

• Using one rule to start a loop process, which triggers a recursive, Incoming Webhook triggered rule to process the items one at a time
• Assuming a rule triggered on a specific field change, create a recursive rule which uses the Lookup Issues action with JQL containing an ORDER BY clause, grabs the first matching issue to perform actions on it, flags it somehow as "updated for the rule", and finally makes another update to trigger recursion

Both such approaches are likely to encounter service limits for looping and / or processing time.

Two non-rule-based approaches are:

• build a service outside of Jira to perform the sequential processing, using the Jira REST API endpoints, and then call that service from the rule using the Send Web Request action
• you do not describe the problem you are trying to solve with this rule, and perhaps there is a marketplace app which can already achieve that; thus checking the marketplace could help

Kind regards,
Bill