Updating dependent task's dates when predecessor task date changes

[#1]

A question that has been asked by multiple community members recently is:

"When I change the end date of a task, how can I have that change automatically update the start and end date of dependent tasks, while also maintaining the original duration of the dependent task?"

Jira Cloud does not do this inherently, but it can be done with limitations using Automation for Jira.

Disclaimers and Caveats:

1. This solution does not leverage functionality that is available in the Plans feature that is part of Jira Premium and Enterprise subscription plans.
   
2. This solution does not rely on third party apps.
3. This solution does rely on the use of the native Issue Linking feature of Jira where the link type used has different values for Outward Description and Inward Description.
   
4. The chain of dependent tasks can be no more than 10 tasks. This is a service limit imposed on Automation Rules that they cannot recursively call themselves or other rules in quick succession more than 10 times.
5. If you set up dependencies between tasks that are in different projects you will need to create a Multiple Project Scoped or Global Scoped rule to be able to edit the issues in all the relevant projects. For more information on rule Scope refer to What are Rule Details? (Scope) 
6. There are monthly Usage Limits for Rule Executions. Consider how adding this rule to your environment will impact your usage. For information on those limits and how usage is calculated refer to How is my usage calculated? 

For this solution I have used the out-of-the-box Issue Link Type named “Blocks”, defined as follows:

• Name: Blocks
• Outward Description: blocks
• Inward Description: is blocked by.

You can use a different link type, as long as the Outward Description and Inward Description are different from each other.

This solution relies on consistent usage of the Blocks issue link type. If A-2 depends on issue A-1 being completed before work on A-2 can start, then this rule assumes that the two issues are linked as follows:

A-1 blocks A-2

Conversely:

A-2 is blocked by A-1

If you have multiple tasks that depend one upon another upon another in a chain, they must be linked in a consistent manner:

A-1 blocks A-2
A-2 blocks A-3
A-3 blocks A-4
A-4 blocks A-5

Also for this solution I have used the following Date Picker fields:

Due date: the date the task is expected to finish

Start date: the date the task is expected to begin

Where I use "Start date" and "Due date" you need to substitute in the names of the fields that you actually use to indicate the starting date and ending date of your tasks.

Here is a summary of the rule:

• Trigger: Field Value Change: Due date is changed
• Condition: Issue Fields Condition: Due date is not empty
• Branch: Related Issues: Linked Issue that are linked by “is blocked by”
  • Condition: Issue Fields Condition: linked issue Start date is not empty
  • Condition: Issue Fields Condition: linked issue Due date is not empty
  • Action: Create variable to hold the current duration of the linked issue
  • Action: Edit the linked issue
    • Set the linked issue Start date to the Trigger issue Due date
    • Set the linked issue Due date to the new Start date + the linked issue duration

Note that in the Branch component you will want to uncheck this box:

The rule components that need more explanation are the last two; Create Variable and Edit Issue Fields

To get the original duration of the dependent task we get the difference in days between the original Start date and original Due date using smart value function diff() described in Automation smart values - date and time . We store this in a variable for use in the next step of the rule - Create Variable.

Note: You can alternately get the duration in business days by using businessDays instead of days.

In the Edit Issue action we use smart values to set the Start date and Due date to new values for the dependent task.

The dependent task’s new Due date is its new Start date plus the number of days calculated as its duration. We stored the duration in a variable we created earlier. We can use the plusDays() function to add that variable value to the new Start date to get the new Due date.

We are changing the Start date in this same Edit Issue action. To avoid any collisions in changing data we will reference the trigger issue’s Due date in setting both the new Start date and Due date for this dependent task.

Start date: {{triggerIssue.Due date}}

Due date: {{triggerIssue.Due date.plusDays(varDuration.asNumber)}}

Variables are stored as strings, so we use asNumber to convert that to a number for this calculation.

When the rule execution completes it will have updated the Start date and Due date of the dependent task. Because it updates an issue Due date, that will cause this rule to be triggered again, with the task just updated becoming the triggering issue for the next execution.

For the rule to be able to operate in this recursive manner you must make sure that you check this box on the Rule Details page:

To learn more about Automation for Jira consider taking FREE self-paced courses from Atlassian University such as:

Automating Jira

Reduce administrative work with Jira Automation

Reducing manual steps for a developer team with Jira Automation

[Bill Sheboy]

Hi, and thanks for the well-written article, @Trudy Claspill 

A couple of suggested improvements could be:

• add links to the relevant documentation (e.g., create variables, date / time functions, etc.) so people can learn more about how the steps work, and
• add to the caveats about potential impacts for excessive execution using up site, rule usage.  (This could occur if recursion is used often with such rules.)

Kind regards,
Bill

[Trudy Claspill]

Thank you for those suggestions, @Bill Sheboy ! I have updated the article as you have recommended.