Working around Jira's rule execution limit?

[Arlene.Amaya]

I have a project that includes 31 linked tasks. We are using Jira to track this project and our goal is to have all tasks triggered at once through automation rules; however, I'm running into some problems with that.

Current set up: 31 automation rules. First task is triggered when an epic is created for this project. The next task is triggered when the former is created and so on until all 31 tasks are created and visible within the epic.

Problem: After a certain amount of rules are triggered, the rule execution will stop and I get the following loop error: 

Rule execution was stopped since an execution loop was detected. Please check *all* your rules and disable the 'Allow rule trigger' setting in 'Rule details' where it is not needed. We stopped execution after detecting a long chain of rules triggering other rules. Chain length: 10

From what I understand, Jira does not like it when too many tasks are triggered at once.

I circumvented this problem by creating two 'breaks'. After the 9th rule in the sequence is triggered "when: issue created," the next rule is triggered "when: issue transitioned from (in progress, awaiting info, etc.) to (done)." The rule after that resumes to "when: issue created" and so on until another break is needed to not trigger the loop.

Question: Is there a solution in which all tasks will be triggered at once without needing breaks in between? One thought I had was to create a single rule with 31 actions (tasks created), but I'm afraid I will still get an error message. Does anyone know if there are indeed limits on the number of actions that can be run within a single rule?

[Mikael Sandberg · Accepted solution]

I would create all tasks within the same automation. Yes, there is a limit on how many components you can have, currently that is 65. So you could brake it up in two rules and either have both trigger on when the epic is created or use a dispatcher rule that is calling each of the two rules via web requests. You can learn more about the limits in automations here.

[Bill Sheboy]

Hi @Arlene.Amaya 

Yes, and...to Mikael's answer:

Without knowing more about the specifics of those 31 linked tasks...I wonder if they can be created in single loop (i.e. branch) within a single rule.  Perhaps if you share some details the community can offer ideas.  Thanks!

Kind regards,
Bill

[Arlene.Amaya]

Hi Mikael and Bill, thanks for your response! I realize one issue I'm having with creating a single rule is that the actions are not sequenced in a simple manner (Task A blocks Task B which blocks Task C which blocks Task D, etc). 

In our instance, you might see something similar to the following:

Task A blocks Task B, Task C, and Task D

Task C blocks Task E and Task F,

Task D blocks Task G and Task H

And so on.

I've been playing around with branching rules, but it doesn't seem to be compatible with the structure of our task sequence. Does that make sense? Do you have a suggestion on how to work around this?

[Bill Sheboy]

Thanks for clarifying, and you are correct: unless the issues are created sequentially you cannot easily create the "blocks" links in your desired order.

My idea of using a branch may not work if all the issues are in a chain.  The reason is that automation rule branches on more than one issue run in parallel and asynchronously.  And so there would be no guarantee the issues are available to link to...unless they are created one by one.

First thing, I would pause to consider if these items are indeed all blocked in that long of a chain.  Perhaps the dependencies indicate some items are not stand-alone, and could be merged, reducing the number of items.

Another approach is using parent/child issues (e.g. tasks and sub-tasks) to reduce the need for the linkages across so many issues.