How can I transition issues automatically on a specific date?

[Ivar den Hollander]

I want to create issues and when the status of the issues is 'Done' the issues needs to transition automatically to 'Backlog' on the last day of the year. 

So the workflow is 'backlog' -> 'in progress' -> 'review' -> 'done' -> 'backlog'.... and then it repeats.  

I tried to set an automation rule, but I don't think I got it right. 
I set a rule as following: 

When: Scheduled 
Fixed rate 1 every day 
Searches with:  duedate = "{{now.format("2023/12/31")}}

Then: Transition the issue to Backlog 

And: 'Add comment to issue' as I want to automatically want to add a standard comment to the issue. 

I tried to set the date to today to test it, but the issue won't transition to anything. 

The reason that I want this is is as following: 

I want to create issues for different teams with tasks they need to do. The issues need to be placed in their backlog (on their own board) and they got the freedom to complete the tasks throughout the year as long as they complete them before the end of the year. At the end of the year the issues need to be placed back on their backlog again, so the whole thing can start again. 

The issues won't have a set due date or anything. 

How do I need set the automation rule to do the thing I want? 

[Bill Sheboy · Accepted solution]

Hi @Ivar den Hollander -- Welcome to the Atlassian Community!

Have you considered cloning the issues every year (with automation) rather than returning them to the backlog?

I ask this question as your different teams could have different work methods, and so having distinct items would help with Jira tracking of each distinct issue.  Otherwise tracking things like cycle or lead time would just get longer and longer each year when the same Jira issues are reused.  And...that would impact a team's ability to track for improvement measures.

Kind regards,
Bill

[Ivar den Hollander]

Hi Bill,

I have thought about cloning the issues each year, but for us it is important to see the previous work done in the tickets for auditing purposes. 

So the use case of these tickets are that the teams need to provide evidence on how they implemented different ISO controls or how they are going to implement them. So by re-using the issues when can check the progress, but also show an auditing party this to be used during an audit. 

Kind regards

Ivar den Hollander

[Stefan Salzl]

Hi @Ivar den Hollander 

especially in this context I would higjly recommend to clone/re-create the issues. I‘ve seen several regulated systems and this was one of the main points in the audits to have a clear record for each step.

By resetting an issue its not „unique“ anymore, not directly traceable.

Furhermore regarding „to see the work done“:
You would not loose any work or history. The history is in the original issue, where it should be. That‘s one of the main concepts to have clear tracebility on different levels and to bring things to a dedicated end-status and then starting the next one and tracking the history of a new step in a new issue. 

As I can tell from several audits it‘s not sufficient to have eg. 1 task for all work that needs to be done thats then just handed around between different people and move fore- and backwards.

Thus said: I highly recommend and support the solution proposed by @Bill Sheboy 

Best
Stefan

[Ivar den Hollander]

Dear @Bill Sheboy and @Stefan Salzl ,

Thank you for the support!

Kind regards, 

Ivar den Hollander