Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 
  • Community
  • Q&A
  • Jira
  • Questions
  • How to accurately sync child worklogs to Parent issues using Tempo when worklogs are updated or dele

How to accurately sync child worklogs to Parent issues using Tempo when worklogs are updated or dele

Asier Vadillo
Contributor
June 2, 2026

Hi everyone,

We are using Jira Cloud along with Tempo Timesheets for our time tracking. For metrics and reporting purposes, we need the time logged on Bugs to also be reflected/added to their respective Parent issues.

To achieve this, we configured the following automation rule:

Screenshot From 2026-06-02 08-54-49.pngtrigger_log.png

This workflow works perfectly when a worklog is Created. However, we run into major data duplication issues when a worklog is Updated or Deleted.

For example:

1- A developer logs 2h on a Bug. The automation correctly logs 2h on the Parent.

2- The developer later updates that same worklog from 2h to 1h 45m using Tempo.

3- The automation triggers again under "All worklog operations", takes the new value (1h 45m), and adds it to the Parent. Now the Parent has a total of 3h 45m logged instead of just updating to 1h 45m.

We have the trigger in all worklog operations, maybe made another automation flow  with the Updated trigger?

Anyone has run into a similar problem or has any insights regarding mine? Thanks in advance!

Regards,

Asier

2 answers

0 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
June 2, 2026

Hi @Asier Vadillo 

First thing, I am just another customer making a suggestion, and I am not an Atlassian or marketplace vendor employee.  With that out of the way...

 

Your rule is triggered on a change to a field (i.e., time tracking) and you describe using "different epics for each month with different sprints."

There are several ways the total time tracking value across the children could change beyond the field change and the apparent re-assignment of children to new parents every sprint or month.  For example, work item deletion, work item move to a new space, work item type change, etc.  Depending upon when and how accurately you want to track the summed values, consider using:

  • multiple automation rules with different triggers, or
  • investigating marketplace apps to help. 

To learn more about using multiple rules for sum / synch scenarios with parent and child work items, please see this article I wrote on the topic:

https://community.atlassian.com/forums/Automation-articles/Automation-concepts-Sum-or-Synch-Fields-with-Parent-and-Child/ba-p/3162890

 

Kind regards,
Bill

0 votes
Paul Glantschnig _Appfire_
Atlassian Partner
June 2, 2026

Hi @Asier Vadillo,

The duplication comes from the rule adding the worklog value to the parent on every operation. On an update or delete there is no clean amount to subtract, so each event piles on top of the previous total.

The reliable fix is to stop incrementally adding and instead recalculate the parent total from scratch and overwrite it on every worklog operation. That way create, update, and delete all converge on the correct number.

A rule along these lines:

  1. Trigger: Work logged, set to fire on all worklog operations (created, updated, deleted).
  2. Branch / Lookup the children: branch to the parent, then look up its child issues (for example with a Lookup issues action using JQL like parent = {{issue.parent.key}}).
  3. Set, don't add: use an Edit issue action on the parent to set a custom number field (for example "Rolled-up logged time") to the summed Time Spent of the children, via a smart value such as {{lookupIssues.timespent.sum}}.

Because step 3 overwrites the field with a freshly computed total rather than adding a delta, an edited worklog of 2h to 1h 45m, or a deletion, is reflected correctly the next time the rule runs.

One caveat: keep the rollup in a dedicated custom field rather than the parent's own Time Spent, since the latter is derived from actual worklogs and can't be safely overwritten.

Hope this helps, Paul

Paul Glantschnig _Appfire_
Atlassian Partner
June 2, 2026

Following up on the recalculate-and-overwrite automation idea, @Asier Vadillo: if the goal is mainly reporting (seeing each parent's total logged time, including its children), there's a route that sidesteps the sync problem entirely, since there's no automation to keep in step and nothing to double-count.

If you're open to an app from the Atlassian Marketplace, JXL for Jira is a spreadsheet/table view for Jira that rolls Time Spent up the hierarchy automatically. You view your issues as a parent/child tree and add a sum-up on the Time Spent column, so each parent shows the total logged across its children. When a worklog is added, edited, or deleted, the total just reflects the current values, with no rule to maintain.

Time spent rolled up the hierarchy in JXL

It won't write the total back into a Jira field, so if you specifically need that value stored on the parent, the automation approach is still the way. But for a live, always-accurate view it's a lot less to maintain.

Disclosure: I'm on the JXL team.

All the best, Paul

Asier Vadillo
Contributor
June 2, 2026

Hi @Paul Glantschnig _Appfire_ ! Thanks for the answer!

We have a problem here, we use different epics for each month with different sprints. But a bug can be moved from one to another (For example a bug in May, is not finished so we move it to June).

If I follow your approach with the time spent sum of the child issues, the work logged in May would also count for the time in June.

Thanks again! 

Paul Glantschnig _Appfire_
Atlassian Partner
June 2, 2026

I see, you're right, that won't work in this case. Thanks for clarifying.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
ENTERPRISE
PERMISSIONS LEVEL
Product Admin Site Admin
TAGS
AUG Leaders

Atlassian Community Events