Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


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

Creating a Flexible Recurring Task Issue

One of the primary goals of Automation is to provide consistent handling of user triggered events such as transitions of issues, field changes, issues created, or other similar things. The second benefit is to reduce the overhead of administrative functions such as cloning or creating issues, auto-transitioning of issues, sending emails, etc. based on the above triggered events.

Perhaps where this can be seen best is in the creation of recurring tasks. And there’s a couple of ways to go about that. First, if there is a consistency aspect, such as a task is needs to be created on the first day of each month, or on the 15th of the month, or both! This can be done by creating a simple a rule based on a Scheduled trigger.


You can even base the trigger on JQL, if so desired, to cause multiple issues to be created based on other criteria such as Labels or Components.

Or perhaps there is a need for more flexibility, such as cloning a particular card when it gets moved to Done. While you could also achieve that using a Scheduled trigger and a Clone Issue action, you would need to create a rule foe each issue for which you wish to clone.

But what if we could accomplish the goal with a single rule, that fires consistently, but also in a flexible what?!?! Let’s explore how that can be accomplished.

First, create a new custom field with controlled options. That might be a Radio type or Single Picker with a dropdown. As an example, I have created a Single Picker with the options of Weekly, Bi-weekly, Monthly, Quarterly, Annually, 24 Months and 36 Months. I have called the field simply Recurring Need. But you can name it whatever you like. The field would then be placed on the Create and/or Edit screen. You can further control which projects it should be available for by adding a context with limited project names.


Next, we create our Automation Rule. It will be based on when an issue is transitioned to Done. We will also work off of the assumption that the issue will have a value for the Due Date.


After identifying the initial trigger type, we will add a Condition to check if the Recurring Need field is not empty. This will allow any issue transitioning to Done on the project that has a value in the Recurring Need field to keep processing.

Next will be a series of IF conditions for each of the options in the Recurring Needs fields – one for Weekly, one for Bi-weekly, one for Monthly and so on.

After each IF condition, we will include a new action to clone the issue. This will effectively create the “recurring” issue. But it won’t create the issue until the original issue is actually completed – i.e. moved to Done.  In the next screenshot we will see what will the Clone action looks like?


Finally, you will need to adjust the value that gets placed in the Due Date of the CLONED issue. You will need to do that for each Recurring Need value that you use. In the example above, we are working with the Weekly recurring need. So, the Due Date is adjusted to be the Due Date of the original issue plus one week. The Monthly value will use plus 1 month, the Quarterly value will use plus months, etc.

The result is that no matter when you actually close the issue (i.e. move it to Done), the Due Date of the cloned issue will always be in relationship to the Due Date of the original issue.


Let’s look at a quick recap of the use case. I have a task that I want to create a recurring issue for every month. I create the original issue and place a Due Date on the issue and select the Monthly value for the Recurring Need field. Let’s say the Due Date is July 31, 2022. Sometime in July I complete the work (or maybe I am a little late and it’s actually in August – doesn’t matter for the clone), when the card gets moved to Done, the automation will fire and create a cloned issue with a Due Date of August 31, 2022. A completed August card will create a clone for September 30, 2022, and so on.

Notice how it will always us the last day of the month in this case regardless of the number of days in the month. And the great thing is that this will work regardless of the type of project you are using.

Feel free to try it out and/or comment below.


Great description John. Thank you!
We could not use automations because still with that customer on data center and used instead scriptrunner. Our use case was for an employee app that uses for task management Jira as a backend ( 

Like John Funk likes this

Great explanation Mr.John 


Like John Funk likes this


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events