Rolling Up Claim Costs Across Objects
A medical device manufacturer tracks a custom Warranty object whose child Claims also look up to Case and Asset. Finance wants total approved claim cost rolled up to both Warranty and Account, refreshed within minutes of approval. Claim to Warranty is a lookup today because claims are reassigned between regional warranty owners and record ownership must follow the region. There are 1.4 million Claims and 60,000 Warranty records; roughly 900 claims are approved each day. The admin proposes converting Claim to Warranty into a master-detail relationship so a native rollup summary can be created, then rolling up to Account with a cross-object formula.
1. Should Claim-to-Warranty become master-detail? Explain what the conversion breaks and what you recommend instead.
Read the worked answer
What master-detail would break
- Ownership: on a master-detail, the child's owner is always the master's owner. A Claim cannot be reassigned to a regional owner without dragging the Warranty with it. That is the exact requirement the lookup exists to satisfy.
- Reparenting: you cannot change a child's master-detail parent; you move ownership instead, which changes sharing and requires transfer permissions.
- Cascade delete and sharing: deleting a Warranty deletes its Claims, and Claim sharing is forced to follow Warranty.
- Conversion prerequisite: every Claim must have a non-blank parent. With 1.4M rows, orphan claims turn this into a data-cleanup project before any rollup exists.
What the proposal gets right: native rollup summary fields only exist on master-detail, so the motivation is real. The cost is the ownership model, and it loses.
Recommendation
- Keep the lookup.
- Aggregate declaratively: a record-triggered after-save flow on Claim with entry criteria such as
ISCHANGED(Approved_Cost__c) || ISCHANGED(Status)that recalculates the Warranty total with a SUM rather than incrementing it, then updates the Account total in a separate step. - Use the asynchronous path for the parent updates so a bulk approval run doesn't lock parents synchronously.
- Note that the Account figure cannot be produced by a cross-object formula rollup: rollup summary fields cannot reference cross-object formulas, and cannot span two levels. Account needs its own maintained aggregate.
- If performance at 1.4M rows matters more than declarative purity, an Apex trigger plus batch recalculation is the alternative that does not cost you the ownership model.
2. Design the initial backfill for 1.4M Claims and the ongoing reconciliation that keeps Finance's trust.
Read the worked answer
Don't backfill through the automation. Running the record-triggered flow across 1.4M records will take an unreasonable time and blow through limits. A scheduled-triggered flow also caps at 250,000 records per run, so it cannot do this in one pass.
Backfill
- Extract aggregates with Data Loader or a SOQL
GROUP BYon Warranty, producing one row per Warranty rather than 1.4M. - Load the Warranty totals, then run a second, much smaller pass for the 60,000-record Account tier.
- Run off-peak, and freeze the target fields first: field-level security read-only and removed from page layouts, so humans and integrations cannot fight the automation mid-load.
- Immediately after the load, run one full recalculation so drift from in-flight approvals is cleared.
Reconciliation
- A nightly comparison of
SUM(Claim.Approved_Cost__c)against the stored Warranty total, with a tolerance report and an alert to Finance when they differ. - An exception report for approved claims whose parent Warranty field is blank or zero.
- Treat the stored rollups as derived data, not source of truth: Finance should be able to rebuild them at will, which is the real test that the design is sound.
3. The Warranty record page already carries 40 fields across 3 record types, and Service and Finance want different things. Should the team build five page variants?
Read the worked answer
No. Use one Lightning record page with Dynamic Forms and let visibility do the work.
- Dynamic Forms requires the fields to be added to the page as individual field components. Fields that only exist in the compact layout do not count, which is the usual reason a team concludes Dynamic Forms "doesn't work".
- Dynamic Forms honors field-level security and record type, so the 3 record types are handled by filter conditions on field sections.
- For the Service/Finance split, filter on a custom permission (e.g.
Finance_Detailed_View) rather than a profile. Profile-based visibility multiplies every time the org adds a department, which is exactly how this org ended up with eight near-identical profiles. - Reserve separate page assignments for genuine structural divergence, such as different related lists or a different header component. If the only difference is which fields show, that is a visibility rule, not a page.
- Keep the highlights panel to a handful of fields; it ignores Dynamic Forms sectioning.
Trap to test: a field that is required at the page-layout level and then hidden by a visibility rule will still block the save. Walk every record type in a sandbox as both personas before deploying.