How to update parent story's original estimate with sum of subtasks in team-managed project?

[Anna Laptyuhova]

Hi community,

I'm trying to roll up subtask original estimates to the parent story automatically in a team-managed Jira project.

What I've already tried:

1. Edit work item → Additional fields JSON

json

{ "fields": { "timeoriginalestimate": ... } }

Result: field ignored — timeoriginalestimate not available in team-managed

2. Edit work item → timetracking JSON

json

{ "fields": { "timetracking": { "originalEstimate": "..." } } }

Result: edits the subtask itself, not the parent — no "Parent of trigger work item" option in team-managed dropdown

3. Send web request PUT to REST API

https://mysite.atlassian.net/rest/api/3/issue/{{triggerIssue.parent.key}}

Result: 404 — smart value doesn't resolve in URL field

What I need:
When a subtask's original estimate is updated → calculate sum of all sibling subtasks' original estimates → write total to parent story's original estimate field → visible in backlog without entering each story.

Questions:

• What is the correct smart value for parent issue key in Send web request URL?
• Is there any other approach (branch, lookup, etc.) that works in team-managed?
• Does triggerIssue.parent.subtasks.originalEstimateSeconds.sum work in team-managed at all?

Thanks!

[Marc -Devoteam-]

Hi @Anna Laptyuhova 

Welcome to the community.

Whenever you ask for help with an Automation Rule it will help us to help you if you provide:

1. what type of project is this (e.g., company-managed, team-managed, etc.), 

2. images that show your complete rule.

3. images showing the details of any relevant actions/conditions/branches.

4. images showing the Audit Log details for the rule execution.

5. Explain where the issue is.

These questions are not for not willing to help, but to have community members understand on how automation works.

NOTE, you will need a branch to the parent, as you trigger the rule on the sub-taks it needs to branch out to the parent.

{{issue.timeOriginalEstimate}} is the smart value for the field Original Estimate

Also check this post a reference, https://community.atlassian.com/forums/Jira-questions/How-to-calculate-total-time-spent-on-stories-bugs-and-adding-it/qaq-p/2912419 

[Bill Sheboy]

Hi @Marc -Devoteam- 

FYI -- that linked question you provided is for Jira Data Center automation, not for Cloud (which this question appears to be).

And for Cloud, I do not believe the {{issue.subtasks}} smart value contains all of the fields due to just-in-time read access, timing problems, etc.  Thus, a Lookup Work Items action must be used with JQL to gather the subtasks' data for the parent, and then sum with:

{{lookupIssues.timetracking.originalEstimateSeconds.sum|0}}

Then add the units of measure for seconds when updating the parent.

Kind regards,
Bill

[danylo_iliukha]

Hi @Anna Laptyuhova ,

Welcome to the community! A few of the friction points you hit are familiar in team-managed Cloud automation.

Parent issue key: {{issue.parent.key}} is the right smart value when the rule runs on a child work item. It works in JQL (for example inside a Lookup issues action). It often does not resolve reliably in a Send web request URL field, which explains your 404. For this use case, skip the web request and use Edit issue on the parent instead.

triggerIssue.parent.subtasks...: I would not rely on {{triggerIssue.parent.subtasks.originalEstimateSeconds.sum}} in Cloud. Subtask field data is not always loaded on the trigger issue, so a Lookup issues action is the safer pattern

A rule that tends to work:

1. Trigger: Field value changed → Original estimate (scope to your child work type), plus issue created/deleted on child work items.

2. Condition (optional): Issue type is one of your subtask types.

3. Branch: Related work items → Parent.

4. Lookup issues: JQL `parent = {{issue.key}}` (inside the parent branch, `{{issue.key}}` is the story).

5. Edit issue (still on the parent from the branch) → Additional fields:

{
  "fields": {
  "timetracking": {
  "originalEstimate": "{{lookupIssues.timetracking.originalEstimateSeconds.sum|0}}"
  }
 }
}

If the value does not stick, try appending a unit (for example ...sum|0}}s) or converting seconds to hours before writing. Check the rule audit log for the exact validation error.

Why your earlier attempts failed: timeoriginalestimate in Additional fields is often ignored in team-managed projects. Editing `timetracking` on the triggering subtask updates that subtask, not the parent, unless you branch to the parent first. There is no "Parent of trigger work item" target in team-managed Edit issue the way there is in some company-managed setups, so the branch in step 3 is the key step.

Double-counting note: writing the rollup into the story's own Original Estimate can affect time-based reports. If burndown or velocity starts counting both story and subtask estimates, consider rolling up to a separate number field instead and leaving the story's Original Estimate empty.

If you can share screenshots of the rule and an audit-log entry from a failed run, happy to help narrow down any remaining smart-value formatting issues.

Hope this helps,

Danylo

[danylo_iliukha]

Following up on the automation approach, @Anna Laptyuhova: if your main pain is scanning story totals during planning (rather than storing a value in Jira's Original Estimate field), there is a lighter-weight option that does not need rules or REST calls.

If you're open to an app from the Atlassian Marketplace, JXL for Jira lets you view stories and their Back/Front/QA children in a hierarchy and add a sum-up on Original Estimate. The parent row shows the combined subtask total live, with no sync logic to maintain.

You can also add a formula column if you want the total as its own computed column, for example rolling up child estimates with JFL. That still displays in the sheet only; it does not populate the native backlog field. So if you specifically need Original Estimate written on the parent in Jira, stick with automation. For day-to-day visibility across many stories, a saved JXL sheet is often less fragile.

I'm on the JXL team.

Best,

Danylo