Automation concepts – Sum or Synch Fields with Parent and Child Work Items

[#1]

Estimated time to read: 6 minutes

TL; DR: Jira has limited abilities to sum or synch a field with parent and child work items. Community members often ask about this need. Let's describe some sources to help and gotchas beyond the basics. Short answer: it may take several rules to solve this need based on your constraints.

What problem are we solving?

Teams may want to use a single value in both parent and child work items (e.g., Component or Team). They may also want to sum a field from children into the parent (e.g., sum the Story Points to help with roadmaps).

Jira Cloud has limited features for those needs. For Jira Product Discovery (JPD) spaces, those have calculations with custom formulas, yet those calculations are display-only in the UX, and cannot be used elsewhere (e.g., JQL searches, work item export, automation rules, etc.) This is mostly the same for other space types. We want something a bit more reusable. 

What is Atlassian doing to help?

Within JAC, there is an open suggestion to add calculations to custom fields in Jira. That one has been in progress since 1 October 2025. You may watch / vote for it to see what is happening: Calculated custom fields, JRACLOUD-61966. A recent post to that suggestion describes a phased release approach. Remember to watch community articles to see any upcoming release announcements.

Atlassian provides a couple of knowledgebase (KB) articles describing rules for basic cases. If you plan to use these, please consider they need adjustments to improve accuracy and reliability. They are: 

• Sum up story points and display value in parent work item in Jira Cloud  
• How to update parent issue start date and due date from child issues  

Let's talk about CRUD!

Those basic case rules help, and yet they are incomplete. Let's consider other ways a work item may be accessed: Create, Read, Update, and Delete, often summarized as CRUD.

Software developers and rule-writers may use the CRUD acrostic as a reminder of cases to consider when handling work items. The knowledgebase articles partially cover the Create case, Read may not matter for changing the Epic, Update is only partially covered, and Delete is not covered at all with the basic rules. Let's drill down to review other cases, and which rules would help. 

How to: more cases to help accuracy and frequency of updates

Using CRUD as a guide, how could work items be impacted where the Epic's Story Points need changes for our summing up scenario? The cases include at least the following:

1. When a new work item is created with a parent, update the parent Epic
2. When a work item is added to a parent, update the parent
3. When a work item is removed from a parent, update the previous parent
4. When a work item is moved to a different parent, update both parents
5. When a work item changes type such that it no longer has a parent, update the previous parent
6. When the Story Points change in a child work item, update the parent
7. When a person manually changes an Epic's Story Points, re-calculate the value for the child items
8. When a work item is deleted, update the previous parent
9. When Atlassian has an outage preventing rules from running, there is no clear information about which rules will run later to "catch up". A mitigation is creating a scheduled trigger rule to "walk" each Epic to recalculate the sum. The rule may be left disabled until needed.
10. When automation service limits are exceeded, the rules may halt running. Please discuss this with your Site / Product Admin if it happens. They may want to use a daily, scheduled rule rather than run many rules for each work item change.

The original KB article for summing Story Points uses the multiple-event trigger...which in my opinion is a really bad idea when one of the events is issue-created. (To learn more, please check the community for posts about race-track timing defects in rules.) Let's split that to use only the Work Item Created trigger, and clone the rule to create others for update cases of the Parent, etc.

Thus, our basic rule handles case #1. Using rule conditions, some of the other cases may be merged into fewer rules. For example, using a Field Updated Trigger with the Parent, cases #2, 3, and 4 can be combined. Similarly, cases #6 and #7 can be combined using an IF / ELSE condition block in the rule on the work item type. Those merges would get us down to five total rules. Going to the extreme, when you only want the Epics updated daily for the total, a single scheduled trigger rule works (i.e., only use #9 with a daily schedule).

You get to decide! What level of accuracy do you want, when do you want it, and how will it impact your site usage of automation monthly limits. 

Wrapping it up

Whew; that was a lot to cover! And, there are yet more potential gotchas to monitor, such as too many items to update, recursive rules, etc. In my experience, it helps to pause to understand what problem are we trying to solve by summing / synching fields. That may help your team find other possible solution approaches.

Please let me know your feedback on the article, your experience summing / syncing fields, and as always...happy rule writing!