In a Plan, can you automate an epic's start date to adjust if the previous epic's end date is extend

[Maxine Freedman-Thompson]

In the Timeline of a Plan is it possible for epic start and end dates to automatically move when the previous epic's end date is changed?

For example, in the screenshot below, the end date for epic TM-252 is 'Mon, Jul 15, 2024'. This epic blocks the next epic TM-267, which currently has a start date of 'Tue, Jul 16, 2024'.

If I extend the end date of TM-252 to 'Mon, Jul 15, 2024', the dependency link changes to red to show that the two epics are now running concurrently (overlapping by 12 days) and not consecutively:

Is there a way to automate epic TM-267's start AND end date to move on 12 days so that the two epics are running consecutively again and no longer overlap?

[Trudy Claspill]

Hello @Maxine Freedman-Thompson 

You would need to set up an Automation Rule to do that. Are you familiar with Automation Rules?

https://support.atlassian.com/cloud-automation/docs/jira-cloud-automation/

[Maxine Freedman-Thompson]

Many thanks @Trudy Claspill I'll take a look :)

[Maxine Freedman-Thompson]

Hey @Trudy Claspill 

Thanks to your suggestion I've summarised that I need to add automation rules for the start date and due date fields on my epics. However, I've discovered that when I extend or shorten the bar neither of these fields is updated in the issue screen, hence any automation won't work.

Do you know what I'm doing wrong or how I ensure that when the start date and/or due date is changed, either by dragging the bar on the timeline or by updating the fields on the issue screen the other is automatically changed? Looking at other threads, it looks as though this usually happens for other people.

Hold that thought, I think I've solved it :)

[Trudy Claspill]

After dragging the bar to change the dates are you reviewing those changes and committing them to the underlying issues? The underlying issues won't be updated until you review and save the changes.

[Maxine Freedman-Thompson]

Hi @Trudy Claspill 

Yep, I discovered that straight after I'd posted!

I'm now having problems with the automation rule :(

Having not done this before, I'm probably going completely the wrong way about it but this is what I've come up with so far but it doesn't work:

Using {{triggerissue.Due Date.plusBusiness Days(1)}} in the action

Am I anywhere close!?

[Trudy Claspill]

Hello @Maxine Freedman-Thompson 

You did not pick an easy case for you first attempt at Automation Rules! ;-)

Let us first talk about the trigger for the rule. You selected "Issue Linked". That means the rule will be triggered when you create a generic issue link between two issues.

In your original post you said you want to update Epic dates when the dates for the "previous" Epic are changed. If that is the case, then the trigger needs to be "Field Value Changed" with the relevant end date field selected for monitoring. Then the rule would be triggered when the change to the end date is saved.

Next you would want a Condition to check that the trigger issue is an Epic type of issue. That will ensure that the rest of the rule runs only when the dates have been changed on an Epic.

The next step would be For Each: Related Issues: Linked Issue, where you would choose the Link Type you use to indicate the dependency between Epics.

Within the branch you would use the Edit Issue action to update the dependent Epic's dates.

However, updating dates gets a little complicated.

How do you decide by how much the dependent Epic's dates should be changed? If the original Epic's end date is pushed out by X calendar days, then do you want to push the dependent Epic's start and end dates out by X calendar days? In this case you have to include a step in the rule to calculate the value of X so that you can use that to update the dependent Epic.

When you use the Field Value Changed trigger it is possible to access the original and new values of the changed field.

But these values are accessible only as Strings. Since you are referencing a date field, you would need to use smart value functions to convert the String values to Date values so that you could then use the diff function to get the difference between the dates.

Converting the values is simple enough. You would use the toDate function:

original value: {{fieldChange.fromString.toDate}}

new value: {{fieldChange.toString.toDate}}

To get the difference between them you would use the diff() function.

{{fieldChange.fromString.toDate.diff(fieldChange.toString.toDate).days}}

If you have made the date later, you should get a positive number of days. If you have made the date earlier then you should get a negative number of days.

So, now you have a number of days. You need to apply that to the dates in the dependent Epic.

For that you would use the plusUnit() function, where Unit is the time of time period (hours, days, weeks). You would take the value you got above, providing that to the plusDays function, and applying the plusDays function to the field you want to change. In my example I used the End Date field.

{{issue.End Date.plusDays(fieldChange.fromString.toDate.diff(fieldChange.toString.toDate).days)}}

There are some refinements that could be made, but that is basically it.

In addition, on the Rule Details page you would want to check the box that would allow the rule to be triggered by the actions of another rule.

The reason to check that box is because this rule will run and change the Epics directly dependent on the one you changed. But then you probably would want that change to continue to cascade down the chain to the Epics dependent on the ones the rule changed, right? You need to check that box so that the changes made to the first Epic(s) by this rule will cause the rule to be called again because of those changes, and make changes to the next dependent Epic(s) in the chain.

There is another consideration though. How many Epics might you have chained together? This rule would be set up so that once it changed the first dependent Epic, that change would cause the rule to trigger again to see if that changed Epic itself has another Epic depending on it. There is a limit of 10 to the number of times a rule can trigger itself to be executed again in this manner . Are you likely to have a chain of more than 10 Epics?

[Maxine Freedman-Thompson]

Hey @Trudy Claspill 

Thanks for explaining all of that!

Am I right in thinking that I need to create a custom field called 'End date' for this to work?

It doesn't seem to work when I use 'Due date'.

Thanks again!

[Trudy Claspill]

You need to use the fields that have been specified in the plan as the fields used for start and end dates. This can be customized in the plan, so you need to check the plan settings to find out which fields are being used.

[Maxine Freedman-Thompson]

OK, so the specified fields are the start date and the due date and I have used these in the smart values - but it's still not working :(

{{issue.Due Date.plusDays(fieldChange.fromString.toDate.diff(fieldChange.toString.toDate).days)}}

{{issue.Start Date.plusDays(fieldChange.fromString.toDate.diff(fieldChange.toString.toDate).days)}}

What have I missed?

[Maxine Freedman-Thompson]

@Trudy Claspill have I exasperated you!? Do you have any ideas as to why it's still not working for me?

[Trudy Claspill]

Hello @Maxine Freedman-Thompson 

No, not exasperated at all! I've just been really busy with work on Cloud migrations.

An excellent tool to use in debugging rules is the Log action.

https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Log-action

With that action you can write text and values into your rule execution Audit Log. Did you notice the Audit Log link in the upper right corner? If you click that you go to a screen that shows you a log for each time you saved changes to the rule and each time it executes. If you click the Show More link to the right of one of the entries, you get more detail for that entry.

I recommend using Log actions to write the following values into the audit log to confirm the rule is getting the values you expect.

First, the before and after values of the changed field:

• original value: {{fieldChange.fromString.toDate}}
• new value: {{fieldChange.toString.toDate}}

Then the calculation you did to get the difference between the two dates,:

• days difference calculation: {{fieldChange.fromString.toDate.diff(fieldChange.toString.toDate).days}}

Within the loop, write out the original value of each field you plan to change before you change it.

Then write out the value you expect it to change to - that long smart value, i.e.

• {{issue.End Date.plusDays(fieldChange.fromString.toDate.diff(fieldChange.toString.toDate).days)}}

...where End Date is the correct field name for your scenario (due date and start date?).

You might want to be trying all this in a test project with a small data set of Epics, to get the kinks worked out before applying it to your production data.

Share the output from the audit log with us. Let us know if the values appear to be correct. If they don't appear to be correct, tell us what you think the correct values should be.

Are the destination Epic fields getting updated at all? Are they getting updated with the wrong values?

[Rosa M Fossi]

Hi @Maxine Freedman-Thompson , I'm curious... how fares your automation effort?  I landed here while looking for a similar solution.