Automation Rule for Adjusting Due Dates of Cloned Issues

[Schneider_ Christian]

I have a rule that clones an issue. One of the fields being copied is called ‘Frequency’ and can have values like Weekly, Monthly, Quarterly, Semi-Annually, or Annually. When the new issue is created, I want to use the Frequency value to calculate the new Due Date based on the original issue's Due Date.

For example, if the original issue has a Frequency of ‘Quarterly’ and a Due Date of July 1, 2025, the cloned issue should have a Due Date of October 1, 2025.

Could you help me figure out how to set up this rule to calculate the new Due Date for each Frequency type? Thank you!

[Marc - Devoteam · Accepted solution]

Hi @Schneider_ Christian 

Welcome to the community.

So based on your example, and after creation you would need to use an if/else condition in your automation

based on the value of the field Frequency, have an edit action that will edit the due date.

The smart value you can use for a quarter will then be: {{issue.duedate.plusWeeks(13)}}

So other options based on the values the Frequency field can have are:

• Weekly -> {{issue.duedate.plusWeeks(1)}}
• Monthly -> {{issue.duedate.plusMonths(1)}}
• Semi-Annually -> {{issue.duedate.plusMonths(6)}}
• Annually -> {{issue.duedate.plusYears(1)}}

See, jira-smart-values-date-and-time 

[Schneider_ Christian]

Marc, thank you for your answer. I have a follow-up question regarding Jira automation rules.

Here's the example:

1. Original Issue No1: Due Date = 25.10.24

2. Automation Rule - First Clone:

   • Cloned Issue: Due Date = 25.10.24 + 4 weeks = 22.11.24

3. Automation Rule - Second Clone:

   • Cloned Issue: Due Date = 25.10.24 + 4 weeks will be not 20.12.24
   • Expected Due Date: Always 25th of the month

How can I adjust the automation rule so that the cloned issue's due date is always set to the 25th of the actual month, regardless of the interval logic?

[Marc - Devoteam]

Hi @Schneider_ Christian 

instead of PlusWeeks, or PlusMonths you can consider to use PlusBusinessDays (business days are considered to be Monday to Friday, 9am to 6pm)

So instead of using {{issue.duedate.PlusWeeks(4), use {{issue.duedate.PlusBusinessDays(20)}} this will move the issue due date 2o business days in the future.

If you want a specific day of a month, you can use:

{{issue.duedate.withNextDayOfMonth(25)}} ,but there is a catch in this

[Schneider_ Christian]

Maybe I'm misunderstanding this, but if I take the issue with the number "T-01" as an example, which is set to renew monthly with a trigger on the 1st of each month, it seems that the rule "Monthly -> {{issue.duedate.plusMonths(1)}}" only works correctly when creating the first clone. Starting from the second clone, the date is calculated incorrectly because the original task "T-01" is cloned again, adding only 4 weeks instead of the expected 8 weeks. Is that correct?

[Marc - Devoteam]

Hi @Schneider_ Christian 

This is correct.

This is not an option to do with automation, unless you make a clone of the clone.

The smart value in the rule acts on the value in the Due Date field, if that stays the same, it will not update the Due Date with 2 months.

You could create a rule that runs every 1st day of the month, that rule creates and issue with all relevant informant (so don't clone an issue) and then use the smart value for the field Due Date

{{now.withDayOfMonth(25)}}

So don't clone issues, but create rules based on a schedule trigger and just provide al info in the rule, instead of creating a template issue in the system.

[Schneider_ Christian]

Bua! Thanks a lot! Perfect. Now I understand how it works—top!

[Bill Sheboy]

Hi @Schneider_ Christian -- Welcome to the Atlassian Community!

Adding to Marc's suggestions...

You are trying to use a "template" issue to create clones with increasing Due Date values, based on the starting date and an incrementor type: Weekly, Monthly, etc.

To get the dates correct, the rules needs to do one of these:

• when a clone is created, update the starting date in the template issue to be used for future clones
• when a clone is created, use Lookup Issues and JQL to find the current, latest Due Date used, and increment from that value
• always clone from the most recently created clone, rather than from the template issue

Next, you are using fixed incrementor types.  Rather than using if / else condition blocks, I recommend using one of these approaches:

1. use a Lookup Table to calculate every possible date for the options, and then get() the correct one based on the incrementor type: https://community.atlassian.com/t5/Automation-articles/Update-Create-lookup-table-action-improvements/ba-p/2427798
2. use a single, large conditional expression to set the field value: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-conditional-logic/

The first approach will be more readable and maintainable in the rule, while the second one is theoretically faster yet more complicated and prone to implementation errors.

Kind regards,
Bill