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

Brock Jolet_wkfaaa

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

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