nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to prevent duplicate transitions in automation

M K_t5lihz

I use Jira Cloud and set up an automation to transition a task when all its subtasks are transitioned. It works, but if for example a task has 10 subtasks, and I transition all of them together, the automation triggers and transitions the parent task 10 times. Is there some way to prevent all these duplicate transitions? Screenshots of the automation and duplicate transitions in the task history are below. Thanks.

Accepted answers

Bill Sheboy

Hi @M K

Yes, and...to the suggestions from @Marc -Devoteam-

This is definitely a racetrack timing situation, and may require different approaches to solve, depending upon your Jira license level:

When you have Premium or Enterprise Cloud, the Delay() action is available and could be added after the rule starts to pause the action for several seconds.

Without those license levels, and even with them occasionally, you may need some rule restructuring to help. For example, you could explicitly check sibling subtasks before proceeding:

trigger: Work Item Transitioned
action: Re-fetch Work Item Data
condition: Issue Type equals Sub-task
action: Lookup Work Items, using JQL to find all sibling Sub-tasks which DO NOT have the same status as the trigger one

parent = {{triggerIssue.parent.key}}
  AND status != "{{triggerIssue.status.name}}"
  AND issueType = Sub-task

smart values condition:
- first value: {{lookupIssues.size|0}}
- condition: equals
- second value: 0
branch to parent
- ...

This approach focuses on first slowing down a bit with a re-fetch on the trigger work item, and then explicitly checking the sibling sub-tasks...which will take a bit more time. Then, only proceed if we are on the last one, whereby the condition passes.

Even with this approach, it could still fail to work correctly...particularly when Atlassian is in the midst of an automation outage, slow down, etc. One belt-and-suspenders approach would be using two rules:

Your current rule, instead of transitioning the parent work item, sets a flag value in the parent. This may be done with a custom field.
Another rule with a Scheduled trigger, runs every 5 minutes or so, and uses JQL to identify any parents which need transition based on the flag, using the custom field to decide what to do, and then clearing the flag in the parent on the way out.

Kind regards,
Bill

All comments

Arkadiusz Wroblewski

Hello @M K

Your rule is almost correct, but the duplicates come from parallel executions when multiple subtasks transition at the same time. Each execution checks the parent before it has been updated by the others, so they all try to transition it.

One important improvement: instead of using “Copy from trigger work item”, try setting a fixed target status (e.g. “Ready for Testing”) and add a condition like:

parent status ≠ “Ready for Testing” or something like that.

This makes the rule idempotent and prevents repeated same-to-same transitions.

You can also keep the Re-fetch issue data step to improve consistency, but the key change is avoiding the dynamic “copy status” action.

Marc -Devoteam-

Hi @M K

I don't know a way to limit this by a setting.

What if you add a delay action in the rule within the branch?

M K_t5lihz

I can try that, but how do I add a delay? I don't see an action for that.

Arkadiusz Wroblewski

@M K

That will mean you are on standard.

The Delay action is used to pause rule execution (for example to avoid parallel updates), but it’s only available on Premium/Enterprise plans

Bill Sheboy

Hi @M K

Yes, and...to the suggestions from @Marc -Devoteam-

This is definitely a racetrack timing situation, and may require different approaches to solve, depending upon your Jira license level:

When you have Premium or Enterprise Cloud, the Delay() action is available and could be added after the rule starts to pause the action for several seconds.

Without those license levels, and even with them occasionally, you may need some rule restructuring to help. For example, you could explicitly check sibling subtasks before proceeding:

trigger: Work Item Transitioned
action: Re-fetch Work Item Data
condition: Issue Type equals Sub-task
action: Lookup Work Items, using JQL to find all sibling Sub-tasks which DO NOT have the same status as the trigger one

parent = {{triggerIssue.parent.key}}
  AND status != "{{triggerIssue.status.name}}"
  AND issueType = Sub-task

smart values condition:
- first value: {{lookupIssues.size|0}}
- condition: equals
- second value: 0
branch to parent
- ...

Your current rule, instead of transitioning the parent work item, sets a flag value in the parent. This may be done with a custom field.
Another rule with a Scheduled trigger, runs every 5 minutes or so, and uses JQL to identify any parents which need transition based on the flag, using the custom field to decide what to do, and then clearing the flag in the parent on the way out.

Kind regards,
Bill

M K_t5lihz

Thanks, I'll start with trying the first solution and seeing if it helps. It's fine if it still occasionally duplicates the transition, it doesn't cause any real harm, I'm just looking to reduce the status history pollution for most cases.

M K_t5lihz

Unfortunately, the first solution doesn't appear to help. It's either still too fast or the delay is too uniform to prevent the race condition.

That said, clearly the second solution would work, if I decide that the longer delay is worth the clean history. It's just a shame there's no other viable option on a standard license.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

automation