Incident Report

Update Dependent Tasks Using Automation For Jira

November 5, 2024
Trudy Claspill

Multiple community members have asked the following question recently:

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

Consistently Using Block Issue Link Types

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.

A Summary of the Rule:

Screenshot 2024-09-19 at 3.16.13 PM.png

 

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

Screenshot 2024-09-19 at 3.45.06 PM.png

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.

Screenshot 2024-09-19 at 3.17.55 PM.png

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:   Due date:

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

Screenshot 2024-09-19 at 3.20.55 PM.png

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:

Screenshot 2024-09-19 at 3.43.52 PM.png

Want some more Jira tips? Check out Our Guide to Import Linked Issues in Jira from CSV. Or if you're looking for more Atlassian content, check out our Expert Answers to Your Atlassian Community Questions.

Put your Atlassian tools to work

Optimize Your Atlassian Stack with Praecipio

Share this resource
If you found this helpful, share it with your network