Rule Triggering another Rule, Need to Exceed Loop Limit
Asked by Cedric Bridger:

Hello all,

A bit of context for my query:

I have two main rules currently which trigger eachother. One detects when a subtask (Lets call it subtask A) start date is changed and edits the corresponding due date based on a custom variable called 'Sub-task Length in Days)

![Screenshot 2024-08-08 180127.png](https://community.atlassian.com/t5/image/serverpage/image-id/340844iC50EFBEEB5911DC1/image-size/large?v=v2&px=999 "Screenshot 2024-08-08 180127.png")

I also have another rule that detects when a sub-task due date is changed, and changes the start date of the following corresponding linked subtask (Subtask B) to match this due date, such that they would appear synchronous on a Gantt chart.

![Screenshot 2024-08-08 1802302222.png](https://community.atlassian.com/t5/image/serverpage/image-id/340845iEFEA764BDE8F42F5/image-size/large?v=v2&px=999 "Screenshot 2024-08-08 1802302222.png")

However, as I have a significant amount of subtasks in this order (Subtask A-Subtask X), my largest issue is that the loop breaks after 10 iterations. Is there a way my automations could be rewritten to avoid this issue? Is there any way to complete this without automation?

Any help would be appreciated!


Answers:
author: Bill Sheboy
body: Hi [@Cedric Bridger](/t5/user/viewprofilepage/user-id/5564312) -- Welcome to the Atlassian Community!

Answering your last question first: there are probably alternatives in the Atlassian Marketplace to the built-in automation rules, or you could build your own application to make such changes using the REST API endpoints, or you could make the changes in a spreadsheet and import to update the dates, etc.

Back to the original question...

Scenarios like this are problematic for automation rules as we are trying to implement features like cascading / recursive / bi-directional date changes (from project management tools), and so processing can quickly hit the automation service limits. One possible solution is to pick a date-change, direction (forward or backward), and remove the recursion.

Let's confirm that **both of those rules** do not have the *allow rule trigger* option enabled. If they do, this is a unsolvable, rule deadlock condition. Please change so only one rule has the option enabled, or better still...

Assuming only one rule has the option enabled (e.g., the downstream one triggered on the change to Due Date), one approach is:

* disable the allow rule option completely for these rules;
* for the rule triggered on Start Date change, add the additional logic to also edit the Due Date;
* this will eliminate the looping, and only be limited by the 100 issues per branch in a rule; and
* one cost of this change is replicating some logic between rules. (This is assuming the stand-alone rule triggered on change to Due Date is still needed.)

Kind regards,  
Bill

comments: author: Cedric Bridger
body: Morning Bill,

Thanks for the help. I have so far integrated the 2 rules together, but as the automation on task A triggers the same automation on task B (As it edits the start date of linked task B) I still get a max-10 loop error. Attached is my new automation diagram

![Screenshot 2024-08-09 103400.png](https://community.atlassian.com/t5/image/serverpage/image-id/340995i82E64706F0777221/image-dimensions/426x868?v=v2 "Screenshot 2024-08-09 103400.png")

Could you advise if there is any way to avoid this loop error? I may have misunderstood your comment.


author: Bill Sheboy
body: Did you **disable the option** in the rules' details (at the top) for this:
> Check to allow other rule actions to trigger this rule. Only enable this if you need this rule to execute in response to another rule.


author: Cedric Bridger
body: Hi Bill, disabling the option means the automation would not continue for the ongoing tasks.

The way I see it working is;

Changing the start date for Task A auto adjusts the end date for task A based on a given no. of days listed as a Jira Smartvalue. The code also changes the start date for Task B to be the same as the new end date for Task A.

As task B's start date has been changed, the automation restarts and adjusts Task B's end date based on the corresponding no. of days listed in the task B Smart Value. It also adjusts the start date for Task C to be the same as the end date for task B.

The code reloops again, changing the end date for task C and the start date for task D ect.


author: Bill Sheboy
body: As I first noted, recursive rules like this are unlikely to succeed and stay under the service limits unless there are a very small number of issues and they are used infrequently.

Worse still, just one rule (or issue linkage) error could lead to using all rule capacity, shutting down execution for 12 to 24 hours on your site's automation. That could impact all of your co-workers' rule usage.

Rather than using automation rules, you may want to investigate the Advanced Planning features of higher Jira license levels or marketplace apps to solve this.