Automation on Status change to done when Resolution is set to Done for Story ticket type
Asked by Bijal Patel:

I am trying to set an automation when Resolution is set to Done then change the Story ticket status to Done from Closed. I have tried with simple if-when-then logic but our Story workflow doesn't allow status to transition directly from Closed to Done.

Thus I am following the workflow transition i.e. Blocker--\>Dev Testing--\>PO verification--\>Done. But then getting the below error msg, " Destination status could not be resolved. If using a smart-value ensure this resolves to a numeric status ID or untranslated name for issues (with current status)".

I was able to perform the same sort of automation with the Bug ticket type, but the automation kept throwing errors for Story type. Please advice, if there is a workaround or if i am missing something here. Thank you in advance!

![Status change automation.PNG](https://community.atlassian.com/t5/image/serverpage/image-id/286550iD6A5B779847F7609/image-size/large?v=v2&px=999 "Status change automation.PNG")


Answers:
author: Bijal Patel
body: Solution: What worked for us:

Adding Automation for Jira user in project role "atlassian-addons-project-access".

In other words, adding the above condition in the workflow transitions for Story ticket type.


author: Tim C
body: Hi [@Bijal Patel](/t5/user/viewprofilepage/user-id/5192059)

I'd suggest adding a direct transition from "Closed" to "Done" (called 'auto-close' or something) and make sure there's no screens, conditions or validators on that transition.

Alternatively, you could share the existing transition to "done" (from the "closed" status) assuming there's no screens associated with it and/or any conditions or validators are true.

The "Resolution" field should only be set on transition to Close. Hence, use this transition to trigger your rule and then check whether the resolution field is set to "Done". If so, then automation should transition to "Closed".

The following works fine for me...

![Screenshot 2023-10-17 085905.png](https://community.atlassian.com/t5/image/serverpage/image-id/286640iB307FC454B6AB795/image-size/large?v=v2&px=999 "Screenshot 2023-10-17 085905.png")

I hope this helps?

Thanks,

TC.

comments: author: Bijal Patel
body: [@Tim C](/t5/user/viewprofilepage/user-id/4438063) - I have tried this but getting the same error msg. See below.

![A1.PNG](https://community.atlassian.com/t5/image/serverpage/image-id/286740iA15D063838818AE8/image-size/large?v=v2&px=999 "A1.PNG")


author: Tim C
body: Hi [@Bijal Patel](/t5/user/viewprofilepage/user-id/5192059)

Did you add an extra transition directly from "closed" to "done" in your workflow(s)?


author: Bijal Patel
body: I would, but unfortunately we are not allowed to make any modification to the existing workflow. And that is why I am looking for a workaround :(


author: Tim C
body: Hi [@Bijal Patel](/t5/user/viewprofilepage/user-id/5192059)

If you can ... try to get your jira admin to add the extra transition then that's the simplest route. You could get them to add a condition on this transition to limit it only the specific user (actor) for the rule - or add a new group in which the actor belongs (e.g. "automation for jira" is usually the default actor?).

However, if you really can't get a change to the workflow - then you'll be forced to go down your original suggested route of moving them through series of transitions ...

* closed
* blocker
* dev testing
* po verification
* done

It's not very efficient - but I think you may need 4 separate rules - one looking for each of the corresponding transitions and passing onto next one (i.e. allowing you to automatically move tickets in between the 5 statues).

Any conditions or validation used on any of these transitions would also need to be successful as part of the automation. Also, if there's any workflow screens being displayed on any of these transitions then again this may restrict the rule from running.

I hope this helps?

Thanks,

TC.


author: Boldizs?r Vermes
body: [@Bijal Patel](/t5/user/viewprofilepage/user-id/5192059), it seems that the automation could not move the issue from Closed status to Blocker. Is it really a valid transition? Are you able to move the issue from Closed to Blocker manually?

comments: author: Bijal Patel
body: [@Boldizs?r Vermes](/t5/user/viewprofilepage/user-id/5089142) - Yes, I can manually moved the issue from "Closed" to "Blocker". Infact it can ONLY move to "Blocker" stage when the issue is "Closed". see below:

![A2.PNG](https://community.atlassian.com/t5/image/serverpage/image-id/286742i7F0470BCE751D7DA/image-size/large?v=v2&px=999 "A2.PNG")


author: Boldizs?r Vermes
body: [@Bijal Patel](/t5/user/viewprofilepage/user-id/5192059), can this transition be restricted to some role or similar? Could you try to switch the Actor of the role among the Role details to yourself?


author: Bijal Patel
body: [@Mikael Sandberg](/t5/user/viewprofilepage/user-id/853579) - I have attached the workflow for your review.   
We are using Resolution Jira system field.

Condition formatting is implemented when transitioning to "Closed" status, Popup window shows up for a user to provide a reason for closing the ticket out.

User should only be choosing "Closed" for special cases e.g. Duplicate ticket, Cancelled Requirements, etc.

In our case; User is selecting "Closed" as a ticket status and in the resolution field they are selecting "Done".

What I am trying to do here is : When resolution is Done/fixed/pass/resolved then change the Ticket status to "Done" instead of "Closed"

![story WF.PNG](https://community.atlassian.com/t5/image/serverpage/image-id/286582iBB41B78B0C2513E4/image-size/large?v=v2&px=999 "story WF.PNG")

comments: author: Mikael Sandberg
body: You said you had a similar automation for bugs that works, correct? And are both bugs and stories using the same workflow? Does the global transition to Blocker have any conditions on it?


author: Mikael Sandberg
body: What does your workflow looks like? When are you setting the resolution? Normally the resolution is set as part of a transition since that field becomes required when it is added to a screen.