How to get sub-tasks to inherit Parent task start/end dates

[Gabrielle Hitchcock]

Hi all,

I'm quite new to automation and my team is having some issues with the tedious nature of having to modify sub-tasks individually before adjusting the Parent task. I've seen a bunch of questions in how to make the Parent tasks dependent on it's subtasks start/due date but our team isn't probably going to leverage sub-tasks on a granular level.

That being said, if I have a parent task that lasts 5 days (with the due dates 11/13-11/17), what do I have to adjust/automate/etc. to get the subtasks to just match the start and due date of the parents tasks (i.e. 11/13-11/17)? 

[Trudy Claspill · Accepted solution]

Hello @Gabrielle Hitchcock 

Welcome to the Atlassian community.

You will need multiple rules to manage this.

Rule #1: When the start date of the parent issue is changed, update the start date of all the subtasks.

Rule #2: When the due date of the parent issue is changed, update the due date of all the subtasks.

Rule #3: When a new subtask is created, copy the start and due date from its paren.t.

Another scenario to consider is when a subtask is changed to have a different parent issue.

Also, what if either the parent issue or the subtask is already in a "done" status? Do you want the subtask dates updated then?

What if the parent issue dates are empty or cleared? Do you want the subtask dates updated to match?

Are there any other conditions where you would not want the subtask dates updated?

Alternately you could have a scheduled rule that checks for all issues that have subtasks and updates them with their parents' dates.

Here is Rule #3:

A clever part of this rule is the Edit Issue action.

First you have to select the field you want to edit. (Note that you can edit more than one field in the action.)

After you select the field, initially you'll see an empty field where you can enter the value you want to assign to the field. The clever part is you can actually select to Copy the value from the parent issue thus:

Click the three dots to the right of the field and select Copy.

That changes the entry field to look like this. Then click on the text displayed in the entry field.

When you click on that text you get a pop-up where you can change the source issue you want to copy from, and even the field you want to copy from. You would want to select Parent Issue as the source.

That's it for Rule #3. I'll post a separate  response about an example of Rule #1/#2.

[Trudy Claspill]

For Rule #2 here is an example. You should be able to extrapolate from this to create Rule #1.

The Trigger is Field Value Changed. You specify the field you want to monitor with this rule. When that field changes, this rule is triggered.

The next step is to add a condition to check the type of issue in which the field changed. You don't want this rule to run if the field changed in a Sub-task or an Epic, as neither of those issue types has child subtasks itself.

The next step is a For Each branch. At this point we know that the issue type whose field was changed is not an Epic or a Sub-tasks, so it is a type of issue that may have child subtasks. We want to update all of its child subtasks.

After selecting the For Each branch you want to select the Related Issue option.

Then choose the type of related issue. In this case you want to execute action(s) For Each Subtasks

Then within the branch you want to add an Edit Issue action, just like you used in Rule #3.

You can use this same rule structure selecting Start date as the field you want to monitor and Edit, for Rule #1.

[Gabrielle Hitchcock]

Hi Trudy! This worked perfectly. Thank you so much for your help and time!

[Kevin Dow]

This is awesome, @Trudy Claspill . I'm also new to automation, and this is precisely the kind of step-by-step explanation I needed to solve for my use cases. Thanks!

[Amanda Brooks]

So helpful, thank you!