Want to ensure I am approaching an automation the best possible way.

[Jason Krewson]

I want to ensure that I’m approaching an automation I am building in the best way possible before diving deep into its creation.

The automation aims to synchronize data between Monday and Jira. Essentially, specific fields selected in Monday will trigger the creation of an Epic in Jira.

Once the Epic is created, Jira will check a field called "Product," which has 81 different options. Based on the selected product, the Epic’s parent field will be updated with a corresponding Initiative. Additionally, two people that own that product will be emailed, these individuals are unique for each product.

To implement this, I set the automation to trigger when an issue is created with the type set to Epic. I anticipate having 81 if/then statements: if product 1 is selected, then add Initiative 1 to the Parent field and email the respective owners, and so on. The attached screenshot demonstrates this setup and it is currently functioning when testing.

Although I proposed using a distribution list, that suggestion was rejected. Even with that, there would still be 81 unique products, 81 unique Initiatives, and thus 81 if/then statements. Is this the most effective way to build this automation?

We use Jira Cloud.

Thanks for the help and suggestions in advance! 

(the blacked out data is just my email)

[Trudy Claspill]

Hello @Jason Krewson 

There is a limit of 65 components in a rule. You won't be able to have a rule with 81 if/else blocks.

Instead of using IF/ELSE statements you might want to consider creating Lookup Tables.

 https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Create-lookup-table

You would create at least two tables of key/value pairs; one table would be the key/value pair for associating the Product values with Initiative values. The second table would be for associating associating the Products  to the emails that need to receive the message. You might need two tables for emails if every product has 2 people that need emailing.

[Jason Krewson]

On no there is a limit! 

Thanks so much for the reply, I will look into creating lookup tables.

[Trudy Claspill]

Another alternative is to record the Product and email recipients in the Initiative.

Then you use the Lookup Issues action to execute a JQL to find the Initiative with the matching Product.

Get the Initiative Issue Key from the Lookup Issues result, and use that to set the Parent of the Epic.

You might not be able to get the email recipients listed in the Initiative through the Lookup Issues results. There are some limitations on what fields for an issue can be accessed through Lookup Issues. You might instead have to use a For JQL branch with the Initiative issue key to change focus to the Initiative issue so you can reference the email recipients information recorded there.

It becomes a choice between where you want to maintain the data; in Lookup Tables in your rule or in the corresponding Initiative.

If your Epics and Initiatives are in different projects, though, getting the data with Lookup Issues and For JQL would require that your rule be scoped for Multiple Projects. Using Lookup Tables would allow you to have the rule scoped for the single project that contains your Epics.

[Jason Krewson]

Thanks for his idea as well, I will dig into both of your ideas and also think about what we are trying to accomplish here and start rebuilding.