Parent account rollups
When accounts have child rows linked by parent_account_id, FunnelStory maintains two helpful rollup fields on the parent (and on any account that has children):
| Field | Meaning |
|---|---|
aggregate_amount | This account’s amount plus the amount of each direct child account. |
earliest_child_expiry | The earliest expires_at among: this account’s own expires_at (if set) and each direct child’s expires_at. |
These are updated during Account model refresh after child rows are upserted. They are intended for revenue dashboards, renewal views, and filters that reference subscription-style totals on parents.
Rollups use one hierarchy level: each child’s own amount and expires_at, not the child’s aggregate_amount and not grandchildren. Example: if Global → Region → Account, Global’s aggregate_amount includes Region’s amount only, not the leaf Account’s amount unless that amount is included in Region’s row in your source query.
If you need full-subtree revenue on the top node, aggregate in your warehouse query (for example sum all descendant contracts into the top row’s amount) or flatten the tree for reporting.
How this appears in the product
In list and detail experiences, subscription-style columns on a parent may show aggregate_amount instead of only the parent row’s native amount, and renewal timing may reflect earliest_child_expiry. Exact column labels follow the FunnelStory UI for your workspace.
Underlying account fields remain:
amount/expires_at— what you mapped from your source for that row.aggregate_amount/earliest_child_expiry— computed helpers for parent-style reporting.
Configuring your data for sensible rollups
- Put contract or ARR you want summed at the parent on child accounts when children are the economic sold-to entities; parent
amountcan be zero or corporate-level ARR depending on how you report. - Set
expires_aton children when renewals happen at the child; the parent’searliest_child_expirysurfaces the next renewal in the subtree one level down. - Use
is_containeron pure grouping parents so teams know not to expect standalone product motion on that row — see Setting up hierarchy.