nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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!

Accepted answers

Marc -Devoteam-

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

All comments

Marc -Devoteam-

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:

Original Issue No1: Due Date = 25.10.24
Automation Rule - First Clone:
- Cloned Issue: Due Date = 25.10.24 + 4 weeks = 22.11.24
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?

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:

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
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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

automation

due-date

jira-automation