Help in Automation that sets the start and end date of a subtasks (complicated scenario)

[Sari Kachorovsky]

I'm trying for 3 days, together with the Chat GPT (that drive me crazy back and forwards) to set an automation in Jira for the following scenario:
See the attached screen, I have Hierarchy of Epic-Story-Subtask. 
I have 2 Custom fields to assist:
Enablement Task Order, Enablement Task is blocked by.
Every Subtask gets the Blocked by task. 
I would like that every time start date is changed it will do 2 things:
1. Calculate the end date of this task by adding the Story points to the start date.
2. Find all the subtasks under the Epic level that are blocked by this subtask and update their start date accordingly to the end date of the blocking task. 
I succeeded in a point to get to something, it was not consistance and I'm stuck. I'll really appreciate the experts advice here. Attaching my rule so far (after millions updates to it). 

[Hari Krishna]

Hi @Sari Kachorovsky ,

you are trying to automate dependency-based scheduling for a hierarchy of Epic → Story → Sub-task in Jira.

Each Enablement Sub-task has dependencies defined using two custom fields:

Enablement Task Order

Enablement Task is Blocked By (stores the blocking sub-task key)

The expected behavior is:

When the Planned Start date of a sub-task changes, Jira should automatically calculate the Planned End date by adding the Story Points (treated as number of days).

Any other sub-tasks (under the same Epic) that are blocked by this sub-task should automatically have their Planned Start updated to the Planned End date of the blocking task.

you can able to get partial results, but the rule behaves inconsistently due to multiple updates and re-triggers.

First, calculate the end date for the current sub-task by explicitly treating Story Points as days:

{{issue.Planned Start.plusDays(issue.Story Points)}}

Next, use a single Lookup Issues action to find dependent sub-tasks:

issuetype = "Enablement Sub-task"
AND "Enablement Task is Blocked By" = {{issue.key}}

Then, in a For each issue in lookup issues branch, update the dependent tasks with a guard condition to avoid moving dates backwards:

Planned Start is empty, or

Planned Start is earlier than the blocking task’s Planned End

If the condition is met, set the dependent task’s Planned Start to:

{{triggerIssue.Planned End}}

Optionally, recalculate the dependent task’s Planned End using the same formula to keep the schedule consistent.

It’s important not to update Epic or Story dates in this rule, to avoid multiple lookup actions, and to ensure dates only move forward. With these guardrails in place, the automation becomes predictable and avoids recursive updates.

This approach keeps the logic simple and works within Jira Automation’s limitations for dependency-based scheduling.

[Hari Krishna]

Trigger:
Field value changed → Planned Start

Rule conditions:
Issue Type equals Enablement Sub-task
Planned Start is not empty
Story Points is not empty

Action: Edit issue → set Planned End
{{issue.Planned Start.plusDays(issue.Story Points)}}

Action: Lookup issues using JQL
issuetype = "Enablement Sub-task" AND "Enablement Task is Blocked By" = {{issue.key}}

Branch: For each issue in Lookup Issues

Condition inside branch:
Planned Start is empty OR Planned Start is earlier than {{triggerIssue.Planned End}}

Action inside branch: Edit issue → set Planned Start
{{triggerIssue.Planned End}}

Action inside branch: Edit issue → set Planned End
{{issue.Planned Start.plusDays(issue.Story Points)}}

This rule calculates the end date of the triggering sub-task whenever its start date changes and then shifts all dependent sub-tasks to start after the blocking task finishes. The condition inside the branch ensures dates only move forward, which prevents recursive triggers and inconsistent behavior. The rule does not rely on Epic or Story hierarchy traversal and stays stable by using only the dependency field.