How Can I set the due date of Subtask A to be the start date of subtask B?

[Andrea Unwin]

I would like to make sure that within any of my stories the due date of Subtask A becomes the start date of subtask B. And if there is a change to the due date of A, then the start date of B will change accordingly.

[Trudy Claspill]

Hello @Andrea Unwin 

Welcome to the Atlassian community.

That can be done with an Automation Rule if there is some programmatic way to identify which issue is subtask A and which issue is subtask B.

Do you use a direction issue link between them, like depends on/is depended on by?

Do you have more than two issues in the chain? If so there are some limitations on how many chained issues can be handled by a single Automation rule.

Do you want subtask B's end date changed also, so that it keeps its original duration?

Note that Automation rules can be created by Jira Admins and potentially Project Admins. If you don't have either of those roles you will need to request help to get the Automation Rule created.

[Andrea Unwin]

Right now I have no links set up between them. Each of my 53 stories includes the same Subtask A and B. Yes, I will eventually want to have the same relationship between Subtask B-F. SHould I just make seperate automations for each? And yes, I would like subtask B's end date to change so it keeps its original duration.

[Andrea Unwin]

Thanks for your help with this! Eager to hear your thoughts on how to automate it.

[Trudy Claspill]

In the set of subtasks A-F how do you know which subtask is A, which is B, and so on? As a person looking at the list of subtasks, how do you make that determination?

Does each A task have some unique identifier used in all, and only in, A tasks?

The Automation rule needs some method to programmatically determine which subtask has been changed and which is the subtask that needs to be changed. This might be done by using directional issue linking between the subtasks, or by some other unique but standardized identifying characteristic.

Determining how that sequence of subtasks can be derived programmatically is the first step to figuring out the Automation rule.

[Andrea Unwin]

They are only diferentiated by their names, i.e. "Onboarding, Discovery" etc.

How would I directionally issue link them? 

This is what I have started with. 

[Trudy Claspill]

Is the naming standardized and consistent? Is it always going to be Discovery, Onboarding, etc?

To link the issues directionally...

Let us say I have this set of subtasks.

I want to use directional linking to indicate that they have to be done in this order

CS-256 depends on CS-255

CS-255 depends on CS-208

CS-208 depends on CS-207

If I open CS-256 and click on the Link Issue button, that opens a Linked Issues entry row. (Ignore the field that says "Local".)

In the field the arrow is pointing at, I select "is blocked by", and in the field to the right of that I enter the issue key CS-255. This will indicate that CS-256 can't be worked on until CS-255 is finished.

Select the issue to fill in the field.

Click the Link button to save the link. The result looks like this:

And if we look at CS-255 we see this:

A "directional" link is one that clearly indicates which issue precedes the other. The specific link types you can choose from depend on your system configuration. You'll want to choose a link type that you use in the subtask set only to indicate the order in which they should be done. Don't use that same link type for anything else within a set of subtasks.

So, you can either use directional linking, as long as you have 10 or fewer subtasks linked in the chain, and create one rule that will handle updating them.

Or you can user a standardized naming convention for each issue, and create multiples or a single more complex rule to walk through the chain of issues.

In either case, the trigger should not be Issue Updated. That will cause the rule to trigger for any update to the issue. Instead you can use the Field Value Changed trigger and monitor just the ending date field.

Which of the above methods do you want to tackle - linking the issues or standard naming convention?

[Andrea Unwin]

Thanks for the help with this. yes the subtasks names remain consistent across all 53 stories. I have changed the trigger type. So when I link the subtasks to one another 1) am I able to link them in bulk across all the stories? 2) when I link them will I still be able to set a start and due date estimation? I want to be able to see the duration of each in the calendar view even if the subtask hasn't started yet.

[Andrea Unwin]

I think we go the link route vs the standardized naming

[Andrea Unwin]

do the issues have to be linked as long as I have automation that says to use the due date of Subtask A as the Start Date of Subtask B? 

[Trudy Claspill]

Thanks for the help with this. yes the subtasks names remain consistent across all 53 stories. I have changed the trigger type. So when I link the subtasks to one another

1) am I able to link them in bulk across all the stories?

No, issue linking cannot be managed with bulk changes. 

2) when I link them will I still be able to set a start and due date estimation?

Yes. Linking them does not inherently impact the dates. However, once you set up an automation to start automatically changing dates, then any manual change you make will impact the related issues.

I think we go the link route vs the standardized naming
do the issues have to be linked as long as I have automation that says to use the due date of Subtask A as the Start Date of Subtask B? 

You can use either issue linking to identify which issue should get change (which issue is B to another issue's A) or you can use standardized naming of the subtasks. Don't try to set up rules for both that could run against the same sets of subtasks.

If you have lots of these sets of subtasks already created, and they are named in a standard way, then I suggest you move forward with that methodology.

Two more questions:

1. What if the ending date field is cleared? What impact should that have on the subsequent task's dates?

2. What if a starting date is manually changed? Should that have any impact on the preceding task's dates?

[Andrea Unwin]

I see thanks. Can you walk me through the standardized naming method? 

If the ending date is cleared, then it would be nice to keep the start date of the next one as it was before it was cleraed. It technically shouldn't be cleared though. 

If a starting date is manually changed the duration should still be added to that new start date and create a new due date for that task (which therefore affects the other tasks). 

Is the set up for automation I sent you on the right track? How should I edit it?

Thanks

[Andrea Unwin]

Hey I am curious if there is any response to this? ^^ Thanks!

[Trudy Claspill]

By moving forward with basing your rules on standardized naming that means that you have to have a consistent set of subtasks that are always ordered the same and use identical, or near identical, Summary values. For example

1. The first subtask will always include the word "Onboarding" in the Summary, and none of the other subtasks in that set will ever include "Onboarding" in their Summary.

2. The second subtask will always include the word "Discovery" in the Summary, and none of the other subtasks in that set will ever include "Discovery" in their Summary.

3. And so one with each subtask in a set including a unique word in its Summary that is not included in the Summary of any other subtask in the set, and...

4. Every subtask set is identical, using the same unique Summary words in the same order.

The rule for updating issues based on a change of Due Date would be:

1. Trigger on a change to Due date

2. Confirm Due date is not empty

3. Confirm the changed issue is a sub-task

4. Check that the Summary of the changed issue contains keywordA

5. Branch to related issues based on a JQL statement to get the sub-task under the same parent as the trigger issue, where that sub-task Summary contains keywordB.

6. Make sure the related issue has a Start date value.

7. Create a variable to calculate the duration between Start and Due for this related issue.

8. Edit the related issue to set the Start to the trigger issue's Due date, and set the Due date to the trigger Issue's Due date plus the original duration of this related task.

Details of 5, 7, and 8:

JQL: parent={{triggerIssue.parent.key}} and issuetype=Sub-task and Summary~keywordB

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

On the Rule Details page you would have to check this box:

You would create a rule like this for each pair of issues:

Trigger issue summary contains	Related issue summary contains
keywordA	keywordB
keywordB	keywordC
keywordC	keywordD
keywordD	keywordE
keywordE	keywordF

Do be aware given your use of a Standard subscription plan you will need to consider the limitations on how many rule executions you can have across your entire system in a month. Consider how many other rules are executing in your environment, how frequently you are going to change an ending date, and how many rules that will trigger where actions will be executed. For information on those limitations refer to:

https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/

The rule will have to be adjust to use the fields you're actually using for the starting and ending dates in your issues in the Conditions and in the smart values. Note that field names in smart values are case and spacing sensitive, and if you have multiple fields in your Jira instance that have identical names they you will have to find the field ID for the fields and use that instead.

See if you can get that up and running and then we'll talk about the other rule.

I recommend that you create a separate test project configured the same as your "production" project and test out the rule against the test project first to make sure that it is operating correctly.

If it is not operating correctly, please post back here screen images of the rule you create with details for each step AND the details of the audit log for an execution of the rule where you did not get the expected results.

[Andrea Unwin]

This looks great - i think it is nearly complete. I tried this and it didn't quite work... but I think it has something to do with the sytax in step 7 smart value: {{issue.duedate.diff(issue.startdate).days.abs)

is it supposed to be: {{issue.duedate.diff(issue.startdate).days.abs}} ?

[Andrea Unwin]

I changed the code to: {{issue.duedate.diff(issue.startdate).days.abs}}

but it is still not showing a change to the start date of B when I edit the start date of A.

[Trudy Claspill]

is it supposed to be: {{issue.duedate.diff(issue.startdate).days.abs}} 

Yes, indeed! You caught a typo I made!

but it is still not showing a change to the start date of B when I edit the start date of A.

Hopefully this is a typo on your part. ;-)

Your sentence above says you are expecting that making a change to the start date of issue A will cause a change to the start date of issue B. But you asked for a rule that would change the start date of issue B based on a change to the due date of issue A. 

Did you attend to this part of my response and update the field references appropriately to use the names of your actual fields?

The rule will have to be adjusted to use the fields you're actually using for the starting and ending dates in your issues in the Conditions and in the smart values. Note that field names in smart values are case and spacing sensitive, and if you have multiple fields in your Jira instance that have identical names they you will have to find the field ID for the fields and use that instead.

If your fields names have been updated appropriately in the rule then please provide the following:

1. Screen images showing your entire rule and the details of each step.

2. Screen images showing the actual names of the relevant fields in an issue.

3. The output in the rule execution audit log.

[Andrea Unwin]

[Andrea Unwin]

In regards to the "The rule will have to be adjusted to use the fields you're actually using for the starting and ending dates in your issues in the Conditions and in the smart values. Note that field names in smart values are case and spacing sensitive, and if you have multiple fields in your Jira instance that have identical names they you will have to find the field ID for the fields and use that instead."

I changed the field for KeywordB to "Pre-Audit" and I changed keywordA to "Discovery" so I think I covered those bases. I am not supposed to change the Syntax of "triggerIssue" right? Dont change that to a specific field name?

[Trudy Claspill]

What I am referring to is where I used "startdate" and "duedate".

startdate needs to be changed to the actual name of the field that you are using to record your starting date in your issues.

• If that actual field name is Start date then that is what you need to use in the rule.
• If the actual field name is Start Date with a capital "D" you need to make sure that in the rule you use Start Date with a capital "D".
• If the actual field name is Task startING datE then you need to use exactly that text anyplace I used startdate

duedate needs to be changed to the actual name of the field that you are using to record your ending or due date in your issues. 

Those are places where you are telling the rule to look at a field in the issue. You have to correctly identify the field or the rule won't know where to get the data. If it doesn't know where to get the data it will not necessarily say that is an error. Instead it may say "there is no data to be had from the location you specified, so I will use NULL".

[Andrea Unwin]

The field is Due date. Do I need to make sure there is a space in the line of code as well?

{{issue.Due date.diff(issue.Start date).days.abs}} <- like that?

[Andrea Unwin]

and in step 5, the "For:JQL" do I keep the box for "Only include issues that have changed since last time this rule exectued" unchecked?

[Trudy Claspill]

The rule will have to be adjusted to use the fields you're actually using for the starting and ending dates in your issues in the Conditions and in the smart values. Note that field names in smart values are case and spacing sensitive, and if you have multiple fields in your Jira instance that have identical names they you will have to find the field ID for the fields and use that instead.

If your field names have spaces in them then they should have spaces in them in the smart values.

I will note that Due date is a special case. The system field named "Due date" can also be referenced using "duedate".

and in step 5, the "For:JQL" do I keep the box for "Only include issues that have changed since last time this rule exectued" unchecked?

Yes. Let's go through why.

Let us say that box is checked and the rule has never executed.

Let us say that you have two issues (X-1 and X-2) that have this series of subtasks.

Let us say that the last time the subtasks keywordB was updated in any way for either of these issues was on Monday.

On Tuesday you update the Due date of subtask with keywordA under X-1. That causes the rule to run, and run the JQL to find subtask keywordB under X-1 and update its Start date.

On Wednesday you update the Due date of subtask keywordA under issue X-2. The JQL runs and finds subtask keywordB under X-2. But that subtask was last updated on Monday, and the rule last ran on Tuesday. With the box checked the rule says "the issue I found has not been updated since this rule last ran, therefore I will not update the issue."

And so, the Start date of subtask keywordB under X-2 does not get updated.

If you want the dates to be updated regardless of when the subtasks where otherwise last updated, the box needs to be unchecked.

[Andrea Unwin]

Is "Start date" also a special value or does it need to have a space?

[Andrea Unwin]

I have tried it with a space for Start date and without a space but both failed. Any other thoughts as to why? In the log it keeps saying there is no related issue. 

[Trudy Claspill]

Looking at your issue type Condition I see that it says "Subtask" but in the JQL "Sub-task" is used. Change the JQL to use Subtask

[Andrea Unwin]

okay I will! and "Start date" needs to have a space? or is it special like Due date?

[Andrea Unwin]

Wow its working! The due date of A has become the start date of B!THANK YOU! Is there a another automation I can add on to this chain that also sets the due date of B to be 1 month after the start date of B?

[Andrea Unwin]

Because in the end, I basically want the subtasks within each story to be "pre-populated" with start and due dates so that we can map out in advance when subtasks are expected to happen. Aka when I type in a start date for sub-task A, start and due dates will end up populating for subtask B-E.

[Trudy Claspill]

Your ask was for a rule that would update the start date of a dependent task based on an update to the due date of the task on which it depends. In addition you wanted the dependent task's due date updated in such a way that the original duration of the dependent task remained the same after its start date was updated.

• This logic requires that the dependent task already has a start date and due date so that the duration is known.

Now you are asking to set the start date of the first task, automatically calculate its due date based on some duration, and then set start and due dates for the chain of dependent tasks based on durations that apply to those tasks.

• It is possible to construct a rule to do this, however...
• That is an entirely different logic problem, where the start date and due date of the dependent task are blank and the expected duration is documented somewhere in the task instead.

You can not add to the first rule to make it do something entirely different. You would need an entirely different rule for the second requirement.

And would you expect both rules to operate?

• Would you want the second rule to run only when the dependent tasks have no start date and no due date, but do have a Duration? What if the Duration was also blank?
• Would you want the first rule to run only when the dependent task does have a start date and a due date, and using the duration determined by those dates rather than a duration value noted elsewhere in the issue?
• What if you end up with one or the other date blank, but with a documented Duration?
• What if you end up with a start date, a due date, and a Duration, but the dates don't match the Duration?

You should consider the possible variations in the state of data in the issues and what you would want to happen in each case.

I encourage you to take some time to explore the Automation Rule capabilities and see what you can come up with for the new rule. Given that your new idea is an entirely different requirement, I encourage you to start a new Question post about it when you have questions. You may want to provide a link to this existing post in your new Question to provide additional context.

If my responses have now helped you solve the original question/requirement of this post, please consider clicking on the Accept Answer button to mark this Question as Solved.