Roll-up summary fields are quick to set up but easy to misconfigure. The relationship must be master-detail. The aggregate type and filter shape the recalculation cost. Setting the filter incorrectly forces a full back-fill across every existing master record, which can take hours on large data sets. Build in a sandbox and validate the recalculation behavior before promoting to production.
- Confirm the relationship is master-detail
Open the detail (child) object and check the relationship field. If it is lookup, the master object will not show the roll-up summary field type in the picker. Convert lookup to master-detail only if every child record has a populated parent and the conversion is acceptable for sharing.
- Create the field on the master object
Object Manager, master object, Fields and Relationships, New, Roll-Up Summary. The wizard appears only if at least one master-detail relationship exists. Give the field a name that includes the operation, like Total_Opportunity_Amount__c or Count_Open_Cases__c, so it is self-documenting.
- Pick the detail object and aggregate operation
Choose the detail object from the dropdown (multiple master-detail relationships show as separate options). Pick the operation: COUNT (no source field needed), SUM, MIN, or MAX (each needs a source numeric or date field). Save the operation choice deliberately because changing it later forces a full recalculation.
- Add filter criteria if needed
Click Add Filter to narrow which detail records contribute. The filter uses workflow-style syntax with field comparisons, AND/OR logic, and grouping. Keep the filter simple because complex filters slow recalculation on every detail change.
- Set field-level security and add to layouts
Configure FLS for the profiles that need to see the aggregate. Add the field to the master page layout in a section that signals it is a derived value. Many teams group roll-ups in a "Summary" section so users do not try to edit them.
- Trigger the initial recalculation if data exists
When the field is created on an object with existing detail records, the platform runs a back-fill batch automatically. Monitor the recalculation through Setup, Background Jobs. For large objects, schedule the field creation during off-peak hours because the back-fill consumes API and CPU capacity.
- Test recalculation by editing detail records
Create a new detail record under a master, edit an existing detail's filter-relevant field, and delete a detail record. Confirm the master's roll-up value updates in each case. This proves the formula, filter, and lock behavior all work as intended.
The child object whose records are aggregated. Must be connected to the master through a master-detail relationship.
COUNT, SUM, MIN, or MAX. Changing later forces a full recalculation across every master record.
The numeric or date field on the detail object whose values are aggregated. COUNT does not need a source field.
- Roll-up summaries only work on master-detail relationships. If the relationship is lookup, the field type does not appear. Convert to master-detail or use a third-party rollup tool like DLRS.
- Filter changes on a roll-up summary force a back-fill across every master record. On large objects this can lock related batch jobs for hours, so schedule filter changes during a maintenance window.
- Bulk DML on detail records under the same master can produce UNABLE_TO_LOCK_ROW errors because the master is locked during recalculation. Sort data by master ID or use Bulk API sequential mode to reduce contention.
- Each master object supports up to 25 roll-ups by default, raisable to 40 through Salesforce support. Consolidate filtered roll-ups into one field with conditional source logic if you run out of slots.
- Roll-ups on parents with more than 10,000 detail records can trigger CPU governor limits during bulk loads. Consider Batch Apex with a scheduled refresh as the alternative for very large detail volumes.