How to use Automation condition JQL 'status was Done'

[Laci Kremer]

Howdy,

I'm trying to accomplish the following: do an Automation action of a ticket is pulled to Done not the first time. My idea was to use the JQL condition 'status was Done', so the Automation would do the update when the JQL is true. 

For some reason, the automation runs even for the first time although the ticket was not in the Done status before.

I've tried it putting in an if condition block and add the action to it, but I experience the same behaviour.

It seem that the condition checker evaluates the status after is has been executed.

Please advise how to set up the automation rule.

Best,

Laci

[Alexis Robert · Accepted solution]

Hi @Laci Kremer , 

I would look into the JQL condition, something like "status was done BEFORE -1d" or something like that. With the BEFORE, AFTER and DURING operators you can specify when the action was done.

let me know if this helps, 

--Alexis

[Laci Kremer]

Thanks, 'status was Done before -1m' does the job!

[John Funk]

Hi Laci - Welcome to the Atlassian Community!

I think the WAS IN condition will include those just moving to it. 

One way would be to create a custom number field and default the value to 0. 

Then on a post function to Done, set the value to the current value +1 using Automation.

Then in the above condition, only look for those cards that have a value of = 1. But before you do the condition, add another step prior to Re-fresh the issue to make sure the value gets updated first. 

[Bill Sheboy]

Hi @Laci Kremer  -- Welcome to the Atlassian Community!

Would you please clarify what problem you are trying to solve with this rule?

It would seem there is something you want to do when an issue moves to Done, and that issues can move to Done multiple times.  That may indicate you are actually missing steps in your team's processes (columns/status values) if you are moving things backward and forward as part of your normal working practices.

Best regards,

Bill

[Laci Kremer]

Hi Bill, 

We don't want to optimize for chaos for sure :)  Yes, tickets should not move backwards, but life happens. The process has more steps, and there are situations when a ticket needs to go back a step and move forward again. We'd like to track these situations.

Best,

Laci

[Bill Sheboy]

Thanks for explaining, Laci. 

This seems like a "watch for defect rework" type of situation.  If so, couldn't you just count/increment when an item moves from Done to earlier in workflow (transition from Done to anything, except for cloning)?  Just an idea...  Thanks!