Creating a Flexible Recurring Task Issue

[#1]

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 15^th 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.

RECAP

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.

[Martin Runge]

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 (https://retail-optimiser.de/en/fressnapf-organises-in-store-tasks-paperless). 

[HAYATH SHAIK]

Great explanation Mr.John 

Thankyou

[Suzanne Green]

@John Funk Is there a way to do it with a "Frequency" in months field?   So that if the Frequency field value is 3  it creates the clone in 3 months but if the Frequency field value was 18 then it's clone it with a due date in 18 months?

[John Funk]

Hi @Suzanne Green  - yes, you should be able to do that. You would create a variable based on the frequency field, then use the variable in the due date creation instead of the fixed value.