How can I use a for each within another for each in Jira Automation?

[Brock Jolet]

I am trying to create an automation and am running into a roadblock that regularly pops up. I need to be able to address issues that are two steps away from the trigger issue.

Example:

I have an automation that runs on a schedule and clones all issues with a specific combination of fields. I'm essentially using this to create recurring tasks. This automation works.

I am trying to create a second automation that is triggered when any task is created.

These are the steps it should follow:
* When an issue is created
* If that issue has a linked issue of type "recurs"
* For each of those linked issues of type "recurs"
* Check if sub-tasks are present
* For each sub-task present
* Clone the sub-task as a new task and parent it to the trigger issue

Jira Automation will not allow me to run a second "for each" within the first.

In the attached screenshot, you'll see what I can do on the left and what I want to do on the right.

For more context, I didn't clone the sub-tasks in the initial automation for similar reasons. Since I am running a JQL query on a schedule in the first automation, I was unable to configure the automation to find the sub-tasks of one issue at a time the way I could have if it were a manual trigger.

Any suggestions would be appreciated

[Bill Sheboy · Accepted solution]

Hi @Brock Jolet 

I do not believe that is possible with built-in, nested branching yet...as you can see in this suggestion: https://jira.atlassian.com/browse/JIRAAUTOSERVER-71

I expect this is due to performance issues, as a single project-level rule could easily use a site's full SLA limits with one execution.  And that's assuming no rule logic errors.  :^)

A possible work-around for your use case is to carefully map out the flow, and add an indicator to those linked issues.  Then use a second rule to detect the triggering condition, clone their relevant sub-tasks, and link them based on some stored data to the first trigger issue.  All while ensuring you have a good stopping condition to prevent a run-away error.

As an aside: there are known race-track conditions with the issue create trigger, so you may want to add a re-fetch after that trigger before testing data with conditions.  Otherwise it is possible the trigger can fire before the data is fully available, leading to unpredictable results.

Best regards,
Bill

[Brock Jolet]

Thanks for the reply, @Bill Sheboy .

Good call on the re-fetch.

I'll try your suggestion and see where it leads me.

[Brock Jolet]

I think I've got it working well enough for now.

In each automation that creates recurring task clone, I run a lookup just before the clone.

The JQL "parent in ({{issue}})" returns the list of sub-tasks which I then store in a custom field on the new clone.

I then run an automation triggered by the creation of the clone.

I verify the custom field is not empty.

Then I convert the data back into a JQL query using "issue in ({{issue.customfield}})".

I was able to use this JQL in an "Advanced branch" that allowed me to perform an action on the triggerIssue for each of the items in the JQL query.

Unfortunately I was not able to directly clone the sub-tasks this way, but I can pull values from the original fields individually.

[Bill Sheboy]

Interesting...I have not tried to use Lookup Issues as an input to advanced branching yet.  I probably would have assumed it didn't work and first unpacked that into a created variable for the input.

It does make me wonder if this could be a work-around the limitation of only one Lookup Issues being active at once...Time to experiment a bit.  ;^)