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 · Accepted solution]

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.

[Sari Kachorovsky]

Thanks for trying to help me , I update the rule according to your instructions and it didn't work. The lookup didn't find the blocked subtasks, I fixed it to a working lookup (that I know it finds the correct ones) and I had problem with the condition rule inside the branch.
JQL didn't run, which prevented the JQL condition from passing and its actions from being executed:
Invalid JQL: ״Planned Start״ is empty OR ״Planned Start״ is earlier than 2025-12-23
I'm attaching the current rule, that only set correct the trigger item. but not the blocking ones. BTW I marked the Rule "Allow rule trigger" to ON.
Since the subtasks can be from multiple stories under the EPic I must lookup for all the subtasks under the Epic of the trigger issue that are blocked by.

[Sari Kachorovsky]

[Hari Krishna]

The rule logic is fine — the problem is only with the condition.

Jira Automation cannot use JQL to compare a date field with a calculated value (like the trigger issue’s Planned End). That’s why the JQL condition fails and none of the branch actions run.

The fix is simple: don’t use a JQL condition inside the branch. Use an Advanced compare condition instead:

Check if {{issue.Planned Start}} is empty

OR

Check if {{issue.Planned Start}} is before {{triggerIssue.Planned End}}

Once you do that, the lookup issues will pass the condition and the blocked subtasks will update correctly.

Your lookup and “Allow rule trigger” setting are already fine — it’s just a JQL limitation, not a logic issue.

[Sari Kachorovsky]

@Hari Krishna inside the branch I can't add if/else condition and use the OR. How do you suggest to write the condition?

[Hari Krishna]

In Jira Automation, you don’t need an explicit IF / ELSE to handle an OR.

Inside the branch, add two conditions and set the condition group to “Any of the following conditions match”:

Advanced compare condition
{{issue.Planned Start}} → is empty

Advanced compare condition
{{issue.Planned Start}} → is before → {{triggerIssue.Planned End}}

This achieves the OR logic correctly and avoids JQL limitations.
Don’t use a JQL condition here — smart values only work with Advanced compare conditions.

[Sari Kachorovsky]

Thank you for your help. I've managed to create the final rule that works for me. I will attached it here if anyone will need something similar.