Roll Up Sub-Task Dates to Parent Task Then To Epic

[Kevin Crookes]

Hi,

I'm trying to create an automation whereby when the Start & Due Dates are changed on a sub task(s), these are rolled up to the Parent Task. From here the dates are then rolled up to the Epic.

Thank you.

[Constantin Kireev - Be On Time]

Hi Kevin,

The advice to use two separate automation rules is technically correct and is the standard way to handle this if you absolutely need the data stored in a field. However, as the previous response mentioned, if you're using Advanced Roadmaps, you get 'visual roll-ups'.

The reason most teams still struggle with this - and why they try to build these automations - is that 'visual roll-ups' are only for looking at a screen. They aren't 'real' data. If you need to run a JQL query for 'all Epics ending in October' or sync this data to an external stakeholder report, the visual roll-up is useless. You need the actual field value.

But here is the danger: as you move from 10 tasks to 1,000, these 'field-sync' automations often become a source of instability. You risk hitting API limits or creating 'automation storms' where one date change triggers a hundred updates. In my experience, the only way to maintain a 'Single Source of Truth' without the automation headache is to use a dedicated planning layer that handles the roll-up logic in memory and only pushes the final, validated dates back to Jira.

If you're doing this for a small project, automation is fine. If you're doing this for an Enterprise PMO, I'd advise looking into a more robust scheduling engine so you don't spend your weekends debugging automation loops. There are some decent 3rd party apps on the marketplace for planning and rollups that can help to meet your goal.

Kind regards,
C

[Paul Glantschnig _Appfire_]

Hi @Kevin Crookes,

It helps to split this into two different goals, because Jira treats them very differently.

1. If you mainly want to see the rolled-up bars (like your screenshot). Jira Plans (part of Premium) does this automatically. In a plan, open View settings on the timeline and set Dates to roll up from children. Plans then takes the earliest start date and the latest due date of the child items and draws the parent bar from them, and again up to the epic. Two things to know: the parent's own date fields need to be empty for this to work (a manually set date overrides the roll-up), and these rolled-up dates exist in the plan only. They are not written back onto the work items.

2. If you want the actual Start/Due date fields on the parent and epic populated. Jira won't write rolled-up dates into fields on its own, so this is where automation fits, using the two-rule approach (sub-task to parent, then parent to epic). The important detail is to re-read all children on each run (a Lookup issues action or a branch over children) and set the earliest start and latest due, so that removing a sub-task recalculates correctly. Atlassian has a step-by-step article, How to update parent issue start date and due date from child issues, that walks through the smart values.

If the Gantt view is really what you're after, Plans is the quickest path and avoids building anything.

Best, Paul

[Paul Glantschnig _Appfire_]

Following up on my earlier answer, @Kevin Crookes: if you'd like to see those earliest-start and latest-due values without Premium and without maintaining automation rules, that is something an app can handle too.

If you're open to solutions from the Atlassian Marketplace, JXL for Jira shows your issues in a hierarchical sheet (sub-task under task under epic), and its sum-ups can roll a Min of Start date and a Max of Due date up each level automatically. The parent and epic rows then display the rolled-up dates live as you edit the children, with no rules to build, and it works on every plan tier as well as on Cloud and Data Center.

Disclosure: I work on the team that builds JXL.

Hope this helps, Paul

[Nathalia Carvalho]

Hi Kevin,

Yes, this is possible using Jira Automation.

I would recommend creating two separate automation rules:

• Sub-task to Parent Task
• Parent Task to Epic

This approach makes the configuration easier to maintain, simplifies troubleshooting, and helps prevent unintended automation loops.

For the first rule, trigger the automation when the Start Date or Due Date changes on a sub-task. Then, use a Lookup Issues action to retrieve all sub-tasks related to the same parent issue. Based on the results, update the Parent Task with the earliest Start Date and the latest Due Date.

Next, create a second rule that runs when the Parent Task dates change. Use the same approach to update the Epic with the earliest Start Date and latest Due Date from its child issues.

One important note: if you are using Jira Cloud timelines or Advanced Roadmaps, Jira may already provide visual date roll-ups. However, if you need the actual date fields updated on the Parent Task and Epic, automation is the right approach.

I hope this helps!

[Kevin Crookes]

Hi Nathalia,

I create a new space using the blank template to get me started.

As I said to Jeroen, that's what I'm trying to achieve but using the automation isn't as easy as you'd expect.

This is what I've done so far, but it doesn't appear to work.

[Jeroen Poismans]

Hi Kevin,

I understand what you are trying to do but your question lacks some detail in terms of handling certain cases.

An Epic can have several Tasks and a Task can have several sub-tasks. How do you want this handled? What should the behaviour be when we for example a second sub-task is added to a task, which sync do you expect to happen?

[Kevin Crookes]

Hi Jeroen,

Below is ultimately what I'm trying to achieve.

The red bars show the rolled up start and due date for all the sub tasks within the main task. The blue bars show the same but for the main tasks.

I'm new to Jira and quickly trying to get myself up to speed with it.

Thank you.

[Jeroen Poismans]

Hi Kevin,

What you are after, if you want to achieve this natively, will need some automations. You would think 2 but there are some edge case you need to cover also:

• Sub-task created under Task
• Task created under Epic
• Linked sub-task dates were changed
• Task dates were changed (manually or as a result of sub-task dates changed)
• Existing Task is linked under and Epic

Let me list them for you.

Automation: Sync Sub-task dates to Task

• Trigger: On Sub-task create under Task
• Actions:
  • Get Parent Task Start and Due date
  • If Sub-task Start date before Task Startdate => Edit Task
  • If Sub-task Due date after Task Due date => Edit Task

Automation: Sync Task dates to Epic

• Trigger: On Task create under Epic
• Actions:
  • Get Parent Epic Start and Due date
  • If Task Start date before Epic Startdate => Edit Epic
  • If Task Due date after Epic  Due date => Edit Epic

Automation: Sync Sub-task dates to Task when Sub-task edited

• Trigger: Field changed (Start date or Due date)
• Condition: issuetype = sub-task
• Actions:
  • Get Parent Task Start and Due date
  • If Sub-task Start date before Task Startdate => Edit Task
  • If Sub-task Due date after Task Due date => Edit Task

Automation: Sync Task dates to Epic when Task edited

• Trigger: Field changed (Start date or Due date)
• Condition: issuetype = Task
• Actions:
  • Get Parent Epic Start and Due date
  • If Task Start date before Epic Startdate => Edit Epic
  • If Task Due date after Epic  Due date => Edit Epic

Automation: Sync Task dates to Epic when Task gets linked to Epic

• Trigger: On issue linked
• Actions:
  • Get Parent Epic Start and Due date
  • If Task Start date before Epic Startdate => Edit Epic
  • If Task Due date after Epic  Due date => Edit Epic

IMPORTANT: Make sure you allow these rules to trigger each other, because a change to the Task dates as a result of a change to the sub-task, will have to trigger the rule to update the Epic as well.

PS: In addition to the above you will probably also need similar rules when sub-tasks or tasks get deleted. 

Good luck!