Sub-tasks that have been marked as "Done" automatically change to "To-do" impacting ticket tracking
Asked by Jerin Geevarghese:

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 unnecessary![1.PNG](https://community.atlassian.com/t5/image/serverpage/image-id/172951i559733A6062AB5B5/image-size/large?v=v2&px=999 "1.PNG")![2.PNG](https://community.atlassian.com/t5/image/serverpage/image-id/172950i2EC5E1AB8D51CBB9/image-size/large?v=v2&px=999 "2.PNG")![3.PNG](https://community.atlassian.com/t5/image/serverpage/image-id/172952i22A203D43B47287F/image-size/large?v=v2&px=999 "3.PNG") sub-task status changes.


Answers:
author: Mykenna Cepek
body: 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).

comments: author: Bill Sheboy
body: Thanks, [@Mykenna Cepek](/t5/user/viewprofilepage/user-id/3527113) ! I missed that part regarding the trigger.

__Bill


author: Jerin Geevarghese
body: Hi [@Mykenna Cepek](/t5/user/viewprofilepage/user-id/3527113)

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-task![DetailsSubtask.PNG](https://community.atlassian.com/t5/image/serverpage/image-id/173187i1F1248EF66068977/image-size/large?v=v2&px=999 "DetailsSubtask.PNG")


author: Mykenna Cepek
body: 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](https://community.atlassian.com/t5/image/serverpage/image-id/173190iC1256892E4EE89C7/image-size/large?v=v2&px=999 "Screen Shot 2021-12-09 at 3.13.04 PM.png")


author: Jerin Geevarghese
body: Hi [@Mykenna Cepek](/t5/user/viewprofilepage/user-id/3527113)

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,

Jerin


author: Jerin Geevarghese
body: ![Audit.PNG](https://community.atlassian.com/t5/image/serverpage/image-id/173200iD174A828AD379428/image-size/large?v=v2&px=999 "Audit.PNG")![Some errors.PNG](https://community.atlassian.com/t5/image/serverpage/image-id/173201i198BF16B45151C39/image-size/large?v=v2&px=999 "Some errors.PNG")


author: Mykenna Cepek
body: 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"?


author: Mykenna Cepek
body: 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.


author: Mykenna Cepek
body: 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.


author: Jerin Geevarghese
body: Hi [@Mykenna Cepek](/t5/user/viewprofilepage/user-id/2231007),

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,

Jerin


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


author: Bill Sheboy
body: Hi [@Jerin Geevarghese](/t5/user/viewprofilepage/user-id/4634302)

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,  
Bill

comments: author: Jerin Geevarghese
body: 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](https://community.atlassian.com/t5/image/serverpage/image-id/172953iE57F82484001CA33/image-size/large?v=v2&px=999 "to do.PNG")


author: Bill Sheboy
body: 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"


author: Jerin Geevarghese
body: 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?

Thanks,

Jerin


author: Bill Sheboy
body: 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.


author: Jerin Geevarghese
body: 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?


author: Bill Sheboy
body: 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](/t5/user/viewprofilepage/user-id/3527113) 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.)

Thanks!


author: Jerin Geevarghese
body: Hi Bill,

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

Thanks,

Jerin

![Longscreen capture.png](https://community.atlassian.com/t5/image/serverpage/image-id/173308iA23E0CA59269C903/image-size/large?v=v2&px=999 "Longscreen capture.png")


author: Bill Sheboy
body: 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](/t5/user/viewprofilepage/user-id/3527113) suggests.

Thanks!


author: Jerin Geevarghese
body: 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,

Jerin


author: Bill Sheboy
body: 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.


Tags: atl-gruland

status