Does an automation consider a sub-task and a linked task the same?

[John Ricard]

I set up an automation to change the state of the parent when all the sub-tasks are changed to a specific state.  (I attached the rule below for reference.)

Point 1 -Now we are using linked tasks and the automation seems to be executing more often.

Point 2 - I found that a situation where task 1 is linked to task 2 which in turn is linked to multiple other tasks, some of which link back to Task 2.  This circular situation seems to use up all our automation execution quota very quickly.

Point 3 - I did not set the automation to change the parent task's state when the linked tasks change state, I built the rule to execute when the sub-tasks change state.

Does this mean that automation considers linked tasks and sub-tasks as the same?

If there are no sub-tasks, only linked tasks, why should this rule be running?

If the circular linking is the problem how do I prevent the circular linking of tasks?

[Mark Segall · Accepted solution]

Hi @John Ricard - I think you can do a few tweaks to this to refine/optimize how it is performing.  I think the JQL calls are possibly causing the unwanted behavior.  For example...

• Combine the trigger and first condition.  You should be able to set the issue transitioned trigger so that it only fires when issue is transitioned to In Review
• Your first condition inside the branch could be changed to an issue fields condition where status does not equal ready for QA

This should dramatically reduce the overhead and make the rule work as desired.

[John Ricard]

@Mark Segall

Thank you for your response I have implemented your suggestions.  Please see follow up question in response below.

[Ste Wright · Accepted solution]

Hi @John Ricard 

Linked Issues and Sub-tasks aren't treated the same.

Is this rule just executing? Or is it also actioning (i.e an automated action is taking place). You can tell this from the Audit Log...

• Success = Actioning
• No Action Performed = only Executing

---

For clarity, the rule executes even if it performs no action, or an Issue is filtered out by a condition.

It's likely your rule is executing a lot because the Trigger is so generic. It will trigger when any Issue is transitioned from any Status to any other Status. I'd look to limit this to the parameters in the rule - at minimum, that would be To - In Review.

---

I'd also consider...

• Changing the first Condition to an Issue Fields Condition, and checking the Issue Type = Sub-task. The JQL condition here is adding no specific value, and as above, could be confirmed in the Trigger.
• In the Branch's first Condition, I'd also switch this to an Issue Fields Condition. They're more refined than JQL conditions.

Ste

[John Ricard]

Thank you for your response I have made the modifications suggested to my automation. See below.

Most of the last few hundred status show No Action Preformed and most of them point to the circular task that I indicated in Point 2 above and they are all timestamped either at the same second or up to 4 seconds apart.

Since the execution usage count is updated when a rule fires even if no action is taken could that circular task be using up a huge amount of the execution usage count allocation?

[Mark Segall]

Yes the rule will fire for any issue that transitions to In Review and then quickly exits if it isn't a sub-task.  Question... What is the scope of this rule (Is it a single project, multiple project, or global? 

If it's global, you may want to evaluate whether that's truly needed.  Maybe it can be set for a single project or a more refine multiple project scope.

[John Ricard]

Hi Mark,

Thank you for your persistence with this issue.

There are only three of the large projects using this automation.  They all need it.

[Ste Wright]

Hi @John Ricard 

Even if it's multiple Projects, it's worth limiting the rule's scope if the rule is at a global level.

To do this...

• Go to Jira Settings > System > Global Automation
• Select your rule
• In Rule Details, modify the scope to Multiple Projects
• Select the 3 relevant Projects from the drop-down menu
• Press Save > Publish Changes, so the modification takes effect

This avoids the rule unnecessarily triggering on any other Project, where this transition is possible.

Ste

[John Ricard]

The Rule Details were already set up that way.

I still think that the circular links in Point 2 of my initial message and in the data I provided to you in my response above are involved somehow.

[Bill Sheboy]

Hi @John Ricard 

Jumping in to try to help with the concern you note about execution limits, etc.

I recommend pausing to consider the problem you are trying to solve and if there are other ways to solve it.  As you are triggering on status transitions AND later transitioning other issues in the rule, looping can occur...subject to the automation engine preventing loops it can detect.  And as a result some of your processing may not happen and could go unnoticed.

Some specific ideas to consider...

• First, how might the linkages (parent/child or otherwise) be used by team members to prevent a loop
• How to make the rule's triggering case as narrow as possible and/or add conditions after the trigger to halt execution immediately
• Perhaps add a halting indicator to issues to prevent the looping

Kind regards,
Bill

[Ste Wright]

Hi @John Ricard 

Are there other automation rules running, related to linked issues?

From the screenshot, I don't believe Point 2 would be an issue - unless there is another rule updating lots of Issues to In Review, or this is being done in bulk every week, etc.

Now you've refined the rule, are you still seeing as many No Action Performed audit lines?

You could review your audit log, to review what Issues are triggering the rule - and why they might not require an action. This will help clarify if any rule refinement is possible.

Ste