Jira Automation for Predecessor-Successor Scheduling Shift?

[Matt Leatham]

How can I use Jira Automation to implement the following?

When the Start Date and Due Date are shifted/changed on a (predecessor) task -- and that task has a dependent/successor task ("blocked by" the trigger/predecessor task) -- also then automatically shift/update the Start Date and Due Date on the dependent/successor task.

[Trudy Claspill]

Hello @Matt Leatham 

Welcome to the Atlassian community.

I wrote an article on the topic of adjusting successor/dependent task dates. You may find it useful. Take a look and let me know if you have questions by responding here.

Article Link: Updating dependent task's dates when predecessor task date changes 

[Matt Leatham]

Much appreciated, @Trudy Claspill !  I did find your very helpful article and with your guidance I'm sampling out a rule in a sandbox and Jira Plan now. I think I just need to test out the days vs businessDays. 

[Matt Leatham]

Off to a great start 👍 -- yet also appreciate any insight/suggestions you have on the following?

[Trudy Claspill]

Hello @Matt Leatham 

The example rule did everything based on calendar days, not business days. And it did not factor in any existing gap between the predecessor task end date and the successor task start date. If you implemented the rule as I presented it then the new start date of the successor task should be identical to the new end date of the predecessor task.

Please provide screen images showing the rule as you implemented it, including the details of the Create Variable component and the Edit Work Item Component.

If you want the successor task new start date to be 1 business day after the predecessor task's new end date then you would change the smart value used in the Edit Work Item action to include adding one business day with the plusBusinessDays() function.

my example: {{triggerIssue.Due date}}

vs. adding one business day: {{triggerIssue.Due date.plusBusinessDays(1)}}

If you want to calculate the duration of the successor task in terms of business days then you would use businessDays instead of days with the diff() function as I mentioned in the article:

my example: {{issue.Start date.diff(issue.Due date).days.abs}}

vs. using business days: {{issue.Start date.diff(issue.Due date).businessDays.abs}}

If you want the new end date of the successor task to be set based on business days after having calculated the duration considering business days, you would use plusBusinessDays there instead of plusDays.

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

vs. using business days: {{triggerIssue.Due date.plusBusinessDays(varDuration.asNumber)}}

[Arkadiusz Wroblewski]

Hello @Matt Leatham 

I see what’s happening in your screenshot: your rule is shifting the successor by a calendar delta, so when the predecessor move crosses a weekend the successor ends up “drifting” (and it can even start before/too close to the predecessor’s new Due).

If you want “dependency-style” scheduling, you typically want two things:

Use business-day math for the shift (so weekends don’t count)

Anchor the successor start to the predecessor due date (finish-to-start), i.e. successor Start = predecessor Due + 1 business day (or + lag)

What to change in the rule:

A) Calculate the delta in business days (not calendar days)
When the predecessor dates change, compute how many business days it moved. In Automation smart values you can do business-day operations (e.g. plusBusinessDays()), so don’t use plain plusDays() for this use case.

A common pattern is:

shiftBD = newDueDate.diff(oldDueDate).businessDays
(then apply that shift to the successor dates using plusBusinessDays(shiftBD))

B) Force the successor start to be the next business day after predecessor due
Inside your “Linked issues → blockers / blocked by” branch (where the successor is the current issue), set:

Successor Start date = {{triggerIssue.duedate.plusBusinessDays(1)}}

Then set successor Due date based on its own duration.

C) Preserve successor duration (also in business days)
You need a “duration” value from somewhere. Two easy options:

If you already store duration in a number field (best):
Successor Due = {{issue.Start date.plusBusinessDays({{issue.Duration}})}}

If you don’t have a duration field yet, compute it once and store it (otherwise the rule has nothing reliable to preserve). You can calculate “original duration in business days” from successor’s own Start/Due and write it into a number field.

Why this fixes your exact example:

When Deliverable 1.1 slides by a week and crosses a weekend, your successor won’t just get “+7 calendar days”. Instead:

its start will always snap to the next business day after the predecessor due

its end will remain consistent based on business-day duration

One guardrail !

To avoid endless re-triggering when the rule edits the successor’s dates, add a condition like “only run when changes are made by a user” (or skip if actor is Automation).

Have a great Day.