How to create dynamic looping in Automation for Jira

[#1]

Summary

When creating workflows in Automation for Jira, repeating actions a specified number of times can be a desirable function to have.

While Automation for Jira has powerful Branching Components, they are reliant upon a list of issues, or other entities to act upon. This can be cumbersome to use in place of a number.

Sometimes, a simple "run through this workflow 3 times" is all that's needed. This article will cover creating a pair of Automation Rules that provide this functionality.

Solution

A simple way to handle this would be to use the Create Variable Action as follows:

• Name: cycles
• Value: 1,2,3,4,5,6,7,8,9

Then, we can utilize the Smart Value Branch, like so:

{{cycles.split(",")}}

This will take the Smart Value cycles, which is currently a String type, and convert it into a List type based on the commas. Then, the Branch will go through that List by each entry and perform the corresponding actions.

The upside is that this uses fewer Rule Executions. The downside is that this causes each Branch to be done in Parallel, rather than Sequentially, which means it can't rely on previous executions of the loop, since those are happening at the same time. Imagine this like a race between 9 (or however many) horses.

You can set limits as well as dynamically determine the number of branches, like so:

• cycles: 1,2,3.....50 - this has to be manually written. i.e. there's not a smart value way to generate from 1 to 50 with commas between. See here.
• cyclesLimit: 15 - this comes from a Work Item Custom Field; this is what makes it "dynamic"
• branch:

  {{cycles.substringBefore(issue.cyclesLimit).split(",")}}

---

A more complex way would be to build two Rules, with one being the "looping" rule.

The downside is it will use more Rule Executions. The upside is that it will enforce Sequential execution, so that future executions can rely on past executions being completed. Imagine a relay race where 9 horses are on the same team, and only 1 horse is ever running at a given time.

The structure of this configuration relies upon a few Automation Rule Components:

• Trigger - Incoming Webhook
• Condition - Advanced Compare
• Action - Send Web Request

It is advised that the looping rule be disabled while it is being configured. If the rule is looping continuously, disable it to halt the feedback loop.

The first rule will be structured like so:

Trigger: <the initial action that should begin this process> - This depends on what these rules are achieving and your business needs regarding it.

Action: Send Web Request →

  Web request URL: <Webhook URL>

• Example: https://automation.atlassian.com/pro/hooks/<unique-id>
• This is attained from an Incoming Webhook Trigger on the 2nd Rule.

  Headers:

• Content-Type: application/json   -    Do not check Hidden

  Method: POST

  Web request body: Custom Data

  Wait for response: Do not check either of these.

• Delay execution of subsequent rule actions until we've received a response for this web request
• Continue running the rule even if the request response is not successful (i.e. non-200 response)

The Custom Data should be a JSON Payload that contains the value that will be used to determine how many cycles will occur.

A simple example would be:

{"value": 3}

However, this value can be dynamic. If it comes from a Smart Value, it typically will be.

That is the entirety of the first rule. The second rule is only slightly more complex:

Trigger: Incoming Webhook

• The URL this provides is used in the Send Web Request for the 1st rule. Set Execute this automation rule with to whatever is needed for your use case. The value that will be used is required.

Condition: Advanced Compare → The Value from the JSON Payload is Greater Than 0.

Action: Send Web Request →

  Web request URL: <Webhook URL>

• This is attained from this rule's own Incoming Webhook Trigger. i.e. itself.

  Headers:

• Content-Type: application/json     -    Do not check Hidden

  Method: POST

  Web request body: Custom Data

  Wait for response:

• Check this → Delay execution of subsequent rule actions until we've received a response for this web request
• Do not check this → Continue running the rule even if the request response is not successful (i.e. non-200 response)

The Custom Data should be the same as before, except that it needs to decrement the value first. It is advised that dynamic values are only provided by the 1st rule. This way, since a decrement on a static value occurs in the 2nd rule, the number can only go down. This prevents the 2nd rule from running continuously.

Using the simple example before, it would be like this:

{"value": {{webhookData.value.minus(1)}} }

And that's the entirety of how to accomplish this task. It is important to note that misconfiguration can lead to Automation Rule Throttling, per our Automation Service Limits. Caution should be used when creating these rules for this reason.

If this rule were to receive an Incoming Webhook without the appropriate value, it simply wouldn't run, thanks to the Condition.

Further Reading

• Support Atlassian - Automation service limits
• Support Atlassian - Jira Automation Triggers - Incoming Webhook
• Support Atlassian - Jira Automation Condition - Advanced Compare
• Support Atlassian - Jira Automation Action - Send Web Request
• Support Atlassian - Jira Smart Values - Math Functions

[Susan Waldrip]

Hi @Payden Pringle , thank you for this post, I'm interested in learning more complexity for automation and your article is helpful!

[Bill Sheboy]

Greetings!

Regarding this reference:

...there's not a smart value way to generate from 1 to 50 with commas between

Please see this post describing how to do so using the rightPad() function:

https://community.atlassian.com/forums/Automation-articles/Branching-over-smart-values-in-Jira-Automation/bc-p/1886284#M531

And when the actual counter is needed in the looping, please see the improvement of that method:

https://community.atlassian.com/forums/Automation-articles/Branching-over-smart-values-in-Jira-Automation/bc-p/1921481#M546

Kind regards,
Bill