Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Automation order of operations?


I'm trying to make an Automation rule for the case of transitioning a parent story (with children) to Done. I would like it to:

1. If there are any subtasks that aren't in certain statuses, transition those to Done


2. If there are any subtasks that aren't Done at this point, move the Parent story back to In Progress (or otherwise prevent it from being transitioned to Done)

Here's what I have. In testing, it seemed inconsistent: I saw once or twice where it successfully moved the children to Done, then allowed the parent to stay Done. But then another time I saw it transition the children to Done, and then move the parent back to In Progress.

Is there a race condition between these top-level directives? Or are they supposed to execute / complete sequentially?

done transition.png


2 answers

1 accepted

0 votes
Answer accepted

Hey Stephen - yes, you're definitely running into an order of operations thing. Namely: AUT-517 - Rule branch order is non-deterministic. In some cases it would be better for branches to execute in order.

But I'm also a little confused by your rule.

You want to set all Sub-tasks to Done, but if any were not Done (prior to setting them?) then the parent should be kicked back to In Progress?

That's ... interesting. As my old manager would say -- what's the business case for this?

Because don't the two things kind of contradict? Either all subtasks are Done, and the parent can stay Done, or some subtasks need to completed, and the parent should be kicked back to In Progress.

I don't understand the purpose of automatically moving subtasks to done.

Thanks Darryl!

So, I only want to automatically set some subtasks to done - any that are in the latter half of our available statuses. It would have been more clear if I wrote it that way, but like if they're Merged, Ready for Test, In Test... then at that point I'd feel confident automatically transitioning them to Done.

But if any were To Do, In Progress, or Blocked, then I wouldn't want to auto-transition those to Done, and would want to make sure they don't get missed. And in that case I also don't want the Parent story to stay in Done, bc if so, those children sort of get buried, since they aren't visible on the Board as standalone issues.

I should also mention that we use subtasks for developers breaking down a story into smaller tasks, as well as any bugs filed against the main story during the course of the sprint.

Is there a better way of solving this? 

Ah, ok that makes more sense now. Thanks.

But as I tried to come up with a solution, I hit the same brick wall - rules don't run in order.

@Mykenna Cepek wrote a great rant about this.

I guess you could do something hacky like:

Rule 1: Triggered off of parent moving to Done: Automatically move "Merged", "Ready for Test", "In Test" subtasks to Done and also write a comment back to the Parent saying "Approved Subtasks automatically moved to Done"

Rule 2: Triggers off of Issue commented: if last comment ( {{triggerIssue.comment.last.body}} ) = "Approved Subtasks automatically moved to Done", then do the check that there aren't any other subtasks that are in the "Unapproved" state and if so, kick the Parent back to In Progress.

In rule #2 you'd have to make sure to check the Allow rule trigger checkbox:

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.

Any other ideas, @Mykenna Cepek or @Bill Sheboy ? I was almost going to suggest issue entity properties, but there's no trigger for those...

Like Stephen Lee likes this

Looking at the screenshot of your rule in the original post, it seems you're close, and that maybe a different concern is causing the inconsistency you see.

Have you tried simply putting a "Refresh issue data" action before this conditional:

Screen Shot 2021-01-28 at 9.38.09 AM.png

It occurs to me that caching might be foiling your logic, and the refresh might bring the changes made in the previous looping/branch back into sync with the conditional that scans the sub-tasks again.

If that doesn't solve the problem, I'd go to another step to ensure that I'm understanding exactly what's going on during the rule execution. And that's simply to litter the rule with tactical debugging, in the form of "Log action" components. A few examples:

Rule triggered on {{}} {{issue.key}} with Account='{{}}' and change event: '{{eventType}}'

This, at the beginning of a rule, helps ensure I understand the initial context. Super helpful when sifting through the Audit Log, to remember which test was which.

Found {{}} {{issue.key}} with Status="{{issue.status}}" and changing it to Done.

Putting this after an action that actually updates an issue status does two things: it confirms that the "Edit issue" action executed (since the log action is after it), and it verifies the edited issue before and (assumed) after state.

After first loop.

Something simple like this confirms where I am in the rule. Just a sanity check "did it get to this point?"

A WARNING: The order of messages in the audit log also tends to be non-deterministic. From being a developer I know that some logging frameworks are just that way by design (decoupling potentially multithreaded applications from a necessarily single-threaded "write to log" component - you don't want log messages stomping on each other). So pay very little attention to the ORDER of what you see in the audit log, and focus on the presence/absence and content of the log messages.

Would love to hear about what you learn next!

Like # people like this

Hi @Stephen Lee 

@Darryl Lee is correct about the asynchronous execution of parts of the rule...Specifically there is no guarantee the branch is done before the rest of the rule.

Darryl's suggestion seems like one way to do this: split this into 2 rules, where the first rule's completion sets a condition that can trigger a new rule.

The other way is to change your second condition in your rule, such as this:

  • Trigger: issue transitioned to done
  • Branch: on sub-tasks
    • Condition: sub-task status not in (To Do, In Progress, Blocked)
    • Action: transition to done
    • Action: add comment
  • Condition: if some sub-tasks status not in (To Do, In Progress, Blocked, Done) ...or... status in (any other existing status in your flow)
    • Action: transition to In Progress
    • Action: send email

Changing the second test to include everything you already caught in the branch...but which may have not yet processed, and will prevent the race condition.


Best regards,


Like Stephen Lee likes this

Thanks for all the timely and thoughtful responses everyone!

Mykenna - I appreciate those debugging / logging tips, which will be useful in any Automation going forward!

Bill - Your last suggestion was a total "duh" moment :p that totally makes sense, and I'll give it a try now! 

Like Bill Sheboy likes this

When stuck getting a rule to work (in Jira) I use:

  • Consider if I can invert conditions or make them mutually exclusive so the parts of the rule can run independently and in parallel
  • When sequential processing is needed instead, multiple rules and semaphore techniques are key
  • Worst case solution for race-conditions with parent/children, use re-fetches to slow things down and reload the issue state


Like Stephen Lee likes this

That worked perfectly! Here's my final config, for posterity. Thanks again!


Capture d’écran 2021-01-28 à 9.24.06 AM.png

Like Darryl Lee likes this

@Bill Sheboy deserves the credit for this answer. I'll shoot you some Kudos, Bill. Thanks for the assist!

I always have such a hard time wrapping my head around inverting conditions, but you're right, it's often the way. (See also: Jira Expressions. Oooh, the boolean logic that @David Fischer has had to school me on so often.)

I also appreciate @Mykenna Cepek's words of wisdom. I'm decidedly not a developer, so it's great to have that deeper perspective.

Like Stephen Lee likes this

Also, if there's a better way to solve my overall goal, I'm all ears!

Suggest an answer

Log in or Sign up to answer
Site Admin
Community showcase
Posted in Jira Software

Presenting the "Best of 2020" Jira Software roundup!

Catch up with Atlassian Product Managers in our 2020 Demo Den round-up! From Advanced Roadmaps to Code in Jira to Next-Gen Workflows, check out the videos below to help up-level your work in the new ...

7,184 views 8 28
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you