Why your roll-up summary field isn't available (and what to do about it)

August 4, 2026

You want a field on Account showing the sum of open escalations, you create a new field, pick Roll-Up Summary - and the object you need isn't in the list. Or the field type itself is missing. Nothing is broken: you've hit one of Salesforce's firmest rules.

The rule

**Roll-up summary fields exist only on the master side of a master-detail relationship.** If the child object relates to the parent through a plain lookup, no roll-up - the option simply never appears.

Why so strict? A roll-up is a promise: this number is always correct, transactionally, no matter how child records change. Salesforce can only afford that promise when the relationship guarantees tight coupling - master-detail means every child must have a parent, children are deleted with their parent, and reparenting is controlled. With a loose lookup (nullable, reassignable, orphan-friendly), keeping an always-correct aggregate on every write would be far more expensive, so the platform refuses rather than being slow or occasionally wrong.

Even on master-detail, know the boundaries: COUNT, SUM, MIN, MAX only (no AVG - divide SUM by COUNT in a formula field), a default cap of 25 roll-ups per object (support can raise it), and filter criteria are limited (notably, most formula fields can't be used in the filter).

Workaround 1: convert the lookup to master-detail

The cleanest fix when it fits. Requirements: every existing child record must have the lookup populated (no orphans), and the child can't already have two master-details. Understand what you're signing up for - children now die with their parent (cascade delete), they no longer have their own owner (they inherit sharing from the master), and the parent field becomes required. For genuine "line items of a parent" data - escalations on an account, items on an order - those semantics are usually right, and you get real roll-ups forever.

Workaround 2: a record-triggered flow maintaining a number field

Keep the lookup, add a plain Number field on the parent, and let a record-triggered flow on the child update it on create, update (including reparenting - update both old and new parent!), delete, and undelete. Declarative, visible to admins, good for moderate volumes. The honest caveats: you're now maintaining the promise yourself - miss the reparent case and the numbers quietly drift; very high-volume bulk loads can be slow through flows; and consider a scheduled recalculation flow as a safety net that heals any drift.

Workaround 3: an Apex trigger

Same idea with full control: bulk-safe aggregation (one SUM() query per batch, not per record), every edge case handled explicitly, tests proving it. The right choice at high volume or when the logic outgrows what a flow expresses cleanly. It's also the most code to own - if you'd rather not hand-roll it, the long-standing community tool DLRS (Declarative Lookup Rollup Summaries) packages exactly this pattern.

Choosing

Data is truly parent-owned and orphans make no sense → convert to master-detail and use a real roll-up.
Relationship must stay loose, moderate volume → flow-maintained counter plus a scheduled recalc.
High volume or complex rules → Apex trigger (or DLRS).

---

OrgTide's Build knows this rule: ask for a roll-up over a master-detail and you get the real field - ask for one where only a lookup exists and it builds the flow-maintained counter instead, and tells you why. What Build can generate →