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

Question

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: * Edit work item → Additional fields JSON json{ "fields": { "timeoriginalestimate": ... } } Result: field ignored — timeoriginalestimate not available in team-managed * 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 * 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!

Danylo Iliukha _Appfire_ · Answer

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

Danylo Iliukha _Appfire_ · Answer

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

Bill Sheboy · Answer

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:

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

Kind regards,
Bill