Follow Parent Status if Parent being moved
Asked by Thomas A:

I want to create an automation to move status following the parent status. In the board there are 3 types of issue Epic, Task, and Sub-Task. I already create rule like iamge below. But it does not work well.

![sync1.png](https://community.atlassian.com/t5/image/serverpage/image-id/336940i2825C879E4E8803E/image-size/large?v=v2&px=999 "sync1.png")![sync2.png](https://community.atlassian.com/t5/image/serverpage/image-id/336941i994321020EFDD39B/image-size/large?v=v2&px=999 "sync2.png")


Answers:
author: Bill Sheboy
body: Hi [@Thomas A](/t5/user/viewprofilepage/user-id/5491929)

If your rule detects an Epic transition and then transitions child issues (e.g., Story, Task, etc.) and grandchild (e.g. Subtasks) to match, *why have any child or grandchild issues?* It would seem they are not used to track work items / progress.

Often this type of scenario is inverted: when the first child (or grandchild) transitions to in-progress, move the parent as well. Similarly, when the last child (or grandchild) transitions to done, move the parent to match.

Kind regards,  
Bill

comments: author: Bill Sheboy
body: There are two approaches to to manage the service limit, counting impact when cascading changes through multiple issue levels in the hierarchy:

**Using multiple rules**, where there are separate rules for each hierarchy pair and use conditions to manage that:

* rule 1: epic to task changes
* rule 2: task to subtask changes; this rule would enable the *allow rule trigger* option, but the count will only be 1 for each child issue, so there is no problem unless there are more than 10 child issues in an epic

**Use one rule** , which uses Lookup Issues to first gather all of the issue keys needed, and then uses a JQL branch to iterate over them in one pass. For this approach, the *allow rule trigger* option is not needed.


author: Tharaka_Hettiarachchi
body: Hi [@Thomas A](/t5/user/viewprofilepage/user-id/5491929) ,

your automation rule is correct. Problem is rule is not executing again. Try enabling following option in Rule Details.

Go to Rule -\> Rule Details -\> Enable following option

![Screenshot 2024-07-22 at 16.10.42.png](https://community.atlassian.com/t5/image/serverpage/image-id/336991iC57034B01E379F35/image-size/large?v=v2&px=999 "Screenshot 2024-07-22 at 16.10.42.png")

Cheers!

comments: author: Thomas A
body: is'nt that only if we have two seperate rules to run continously?


author: Thomas A
body: Alright thank you it works now! Why does the naming is ambigous


author: Tharaka_Hettiarachchi
body: We need to enable that to move sub tasks. Because, First it will trigger only child task, then again we need to execute the same task to trigger subtasks. If its correct please mark the answer as correct

Cheers!


author: Thomas A
body: So from my understanding, if we want to run multiple branch we need to enable that feature first, right?


author: Bill Sheboy
body: Hi [@Tharaka_Hettiarachchi](/t5/user/viewprofilepage/user-id/5038012)

Using the option to allow rule trigger may not be a good approach for this scenario.

The reason is a self-triggering rule for three levels of issue hierarchy could quickly trigger more than 10 times and halt rule execution due to service limits for loop detection: <https://support.atlassian.com/cloud-automation/docs/automation-service-limits/>

Kind regards,  
Bill


author: Thomas A
body: What is the solution to solve this case?


Tags: automation

help

jira-cloud