Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Sub-tasks that have been marked as "Done" automatically change to "To-do" impacting ticket tracking

I have configured a series of sub-tasks which auto-populate when a ticket is created and match a certain criteria. These sub-tasks are marked as "To-do" by default when opened. After working on one of them and setting the status as "Done", I proceed to work on the next sub-task which is also completed and marked as "Done". Here is where the problem starts:

After moving the second sub-task to done, the first sub-task that has been set to "done" automatically moves to "To-do", when the page is refreshed. And the series continues with random status' of done and "to-do".

Attaching screenshots for reference, please let me know what can be done to help stop this unnecessary1.PNG2.PNG3.PNG sub-task status changes.

2 answers

1 vote
Mykenna Cepek Community Leader Dec 08, 2021

I'm having doubts that this rule is the one causing the problem, which you said was:

After moving the second sub-task to done, the first sub-task that has been set to "done" automatically moves to "To-do", when the page is refreshed. And the series continues with random status' of done and "to-do".

The rule you posted has an "Issue assigned" trigger, meaning this rule will only execute when the Assignee field is updated.

So if the problem you're seeing occurs when transitioning issues, then this rule is not causing the problem.

To investigate which rules might be in play, look at one of the sub-tasks which have been moved into the wrong status. In the Detail Pane of the sub-task (on the right side), click on "Automation - Rule Executions" and review the "Recent rule executions". From there you can click through to see rules which have been recently run against that specific issue.

My guess is that some other rule is triggering to change the status.

For example, we have rules set up to help keep the status of Stories and their Subtasks in sync. Those kinds of rules could easily explain the symptom you're seeing (if you have such rules enabled for the project of interest).

Thanks, @Mykenna Cepek !  I missed that part regarding the trigger.


Like Mykenna Cepek likes this

Hi @Mykenna Cepek


Thank you for your detailed response. I am trying to follow your advise and look at which automation rules have run, but I cannot find the said  "Automation - Rule Executions" and the "Recent rule executions". Could you please redirect me where to look correctly?

Attaching screenshot of the details tab for the wrong status sub-taskDetailsSubtask.PNG

Mykenna Cepek Community Leader Dec 09, 2021

Hmm, my guess is you're not using Jira Cloud (tip: it helps if you tag your questions here with Jira Cloud, Jira Data Center, or Jira Server).

I haven't used the latter two in many, many years; sorry. Maybe under the "More" menu, or hiding elsewhere in an issue (three-dots menu, suppressed by permissions, or not exposed as a "field" on the "screen", etc)? A little help from my DC/Server community colleagues?

Another option (at least under Jira Cloud) is on the Automation Administration screen, where there are tabs to view things like automation "Usage" and "Audit Log" (see screenshot below).

The latter is NOT a rule-based log, but an automation-wide log of what rules have recently run. If you have that, you can make the problem occur, then quickly check that automation-wide Audit Log to see which rules most recently ran.


Screen Shot 2021-12-09 at 3.13.04 PM.png

Like Jerin Geevarghese likes this

Hi @Mykenna Cepek

Thank you for your response. You're right, this one is under setting and audit logs. I tried to re-perform the action and unfortunately, I dont see any names of the rules executed using other automations rules, I do see some errors - not sure what it exactly means though.


Thanks & Regards,


Mykenna Cepek Community Leader Dec 10, 2021

It looks like only some of the "Action details" are shown above. I only see a couple of notices that look like warnings.

Can you revisit this same execution (match the timestamp) and show the rest of the "Action details"?

Mykenna Cepek Community Leader Dec 10, 2021

The two warnings shown above, "Unknown fields set during create", suggest a (separate) problem with the subtask creation components.

Those warnings identify a "Current Status" field, aka "customfield_15900". Have you researched and/or fixed that problem?

The warning suggest that you "Check your custom field configuration", which is a bit ambiguous. The custom field is probably fine. The field configuration is likely suspect. Ensure that Field Configuration(s) used for this project allow that custom field.

Mykenna Cepek Community Leader Dec 10, 2021

Also, the screenshot above is the Audit Log for this rule. That's not what I was suggesting that you review.

There is a different Audit Log that is global for your Jira instance. It shows all the rules recently executed. Have you found that? It's where you would be able to see what other rules might be triggering around the same time as this rule runs.

Like Bill Sheboy likes this

Hi @Mykenna Cepek,

Thank you for your response! I have not found the audit log you suggested so far. Probably will ask through another thread in the community here and research before performing the steps mentioned to exactly find what we're looking for.

Thanks again and appreciate your support :)

Kind Regards,


Mykenna Cepek Community Leader Dec 10, 2021

Still would help to know if your Jira is Server or Data Center (and which version) or Cloud.

0 votes

Hi @Jerin Geevarghese 

In your branch of sub-tasks, have you considered adding a condition to check if the issue is (or is not) in a particular status before transitioning to "to do"?

For example, you could add a check that the status is not equal to done.

Kind regards,

Hello Bill! Thanks for prompt response.

No I did not consider this as I wanted the sub-tasks to be viewed as "To do" first and then worked on, how can it help though?

where do you suggest I place this - in 1 or 2 (image attached)to do.PNG 

In each location where you branch on sub-tasks and try to transition them, please try this:

  • branch: on sub-tasks
    • condition: status not equal to done
    • condition: status not equal to "to do"
    • action: transition to "to do"

Hi Bill, 

Thank you for your response. I tried to branch the sub-task out by adding condition: status not equal to done

But this does not reflect for the old tickets. Is it only applicable for the new tickets or is it that this solution does not help?



Jerin, let's pause for a second to confirm something please:

  1. Are you trying to create a subtask and then transition that new subtask to "to do"
  2. Or something else

If it is #1 and only the new subtask needs to transition, you can change to branch on most recently created issue, and the problem with altering other "done" subtasks should stop happening.

Hi Bill,

The sub-tasks are already created (not looking at creating new one's additionally) - with the status "To Do", when an assignee is assigned.

I wish to transition the status of these pre-populated sub-tasks to "done", and let it stay as "done". Rather it switches back to "To do"

Hope this clarifies your doubt?

In none of your rule images do I see issues transitioned to "done" by the rule.

Would you please try to post your complete rule as one image?  That will confirm that we are seeing the same thing as @Mykenna Cepek and I try to help you.  To do that, you may need to shrink your browser zoom, grab the image, and crop/scale it back up.  (Or use a screen capture app which handles browser scrolling.)


Hi Bill,

Please find attached the long screen print as requested. Hope this helps!




Longscreen capture.png

Thanks for your complete rule image, Jerin.  

It does appear you are repeatedly creating new subtasks for the trigger issue, and then transitioning them to the "to do" status.  All except the last one, which you leave in whatever the initially created status is.  (perhaps backlog?)

Again I recommend you change each branch to just work on the just the most recently created issue as that is all you appear to need.

  • action: create sub-task
  • branch: on most recently created issue
    • action: transition to "to do"

This should speed up your rule and eliminate the need to test for the "done" status of other subtasks.

If that does not help, I am at a loss of next steps.  And at that point I'm interested what @Mykenna Cepek suggests.


Hi Bill,

Thanks for the response. I tried to recreate what you mentioned on branch: on most recently created issue, unfortunately the status' still flip unnecessarily.

The trigger issue for assignee change takes places only once for our business case, hence it made sense to trigger this for all sub-tasks to be pre-populated. The last sub-task is an optional one, hence left it to Open - to use only if needed.

Thanks for the support so far! 

Kind Regards,


You describe...

  • When you change the branch to most recently created issue
  • Some of the "done" issues still change to the status of "to do"

Then something other than this rule is changing the issues.

Please find an example issue moved from "done" and look at the change history to learn which user made the change:

If that user is the automation user, it is another rule.  Talk to your Site Admin and they can help you find the site's audit log for automation to learn which rules were running when the change occurred.  Together you may investigate why the subtasks are changing.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Atlassian Automation

Jira Automation: Sum Up Story Points Roundup (Initiatives -> Epics -> Story/Tasks -> Subtasks)

Hi Everyone, In this roundup we combine all the jira automation rules to sum up story points across different issue types. We start from the lowest level, summing up story points from sub-tasks t...

3,103 views 10 9
Read article

Atlassian Community Events