Salesforce Roll-Up Summary Without Master-Detail

You wanted one number on the parent record. Total open value across the related deals. Count of inspections completed. The date of the most recent payment. It is the kind of thing that should take four minutes in Setup, and for about half of orgs it does — until you open the field wizard and find that a Salesforce roll-up summary without master-detail is not on the menu. Roll-up summary fields only work across a master-detail relationship. Your objects are joined by a lookup. End of wizard.

What happens next is the part worth talking about. Because the advice you’ll get is usually to change your data model to fit the field, and that is backwards.

The number is not a nice-to-have

Notice what the missing roll-up actually costs. Someone exports the child records to a spreadsheet once a week and pivots them. Or a report exists, and everybody knows the report exists, and nobody looks at it — because a number that lives in a report cannot sit in a list view, cannot fire a workflow when it crosses a threshold, cannot appear on the page the rep is already looking at, and cannot be used in a formula or an alert. Salesforce Ben’s rundown of the options makes the same point about the reporting route: the metrics are “not available as fields in the record.”

That is the difference between a number you can see and a number you can act on. A roll-up on the record is a trigger point. A number in a report is trivia you have to go looking for. Almost every request for a roll-up is really a request for something downstream of it — a queue sorted by total exposure, an alert when a balance clears, a routing rule that reads the count.

Why “just convert it to master-detail” is bad advice

The first suggestion you’ll hear is to convert the lookup to a master-detail relationship. This solves the wizard problem and creates several real ones.

Master-detail is not a stronger lookup. It is an ownership statement. The child record stops having its own owner and inherits sharing from the parent, which means your sharing model for that object is now whatever the parent’s model is. Delete the parent and the children go with it. The relationship field becomes required. If a child ever needs to live under two different parents in different contexts, or exist briefly with no parent at all, master-detail will fight you every week for the rest of the org’s life.

So the trade on the table is: accept a permanent change to how records are owned, shared, and deleted, in exchange for one summed currency field. Teams take that trade all the time and regret it later, usually the first time someone deletes a parent record and takes six hundred children down with it. The data model should describe how your business actually relates these things. It should not be bent into a shape that unlocks a Setup screen.

What the workarounds actually cost

There are three honest alternatives, and each one has a real price tag.

Flow. Native, declarative, no license. It is also the option people underestimate. A roll-up built in Flow is not one automation, it is a small system: recalculate when a child is created, when the relevant field changes, when a child is deleted, and — the one everybody forgets — when a child is reparented, which has to decrement the old parent and increment the new one. Then it needs to survive bulk operations, because the first time someone imports four thousand records the naive version either misses rows or hits limits. Flow can do all of this. But “no code” does not mean “no engineering,” and the version that works in a demo is rarely the version that survives a data load.

Apex. More capable, more testable, handles bulk properly, and the standard objection is the one that matters: it requires someone who writes Apex. That person has a queue, and a request for one summary field does not get to the front of it. This is the real reason the field never gets built — not difficulty, scheduling.

The package route, and what it commits you to

A package. DLRS is the well-known free option: a community-built and maintained app that runs rollups in “Realtime, Scheduled and Developer API modes.” It is genuinely good and a lot of orgs run on it happily. It is also a permanent dependency, community-supported rather than officially supported, and it puts a configuration layer between you and the logic — which is fine right up until you need behavior slightly outside what it configures. Paid AppExchange apps make the same trade with a license attached.

None of these is wrong. The point is that “just add a roll-up” turns out to be a build decision with consequences, which is exactly why it keeps getting deferred.

When master-detail is genuinely the right answer

To be fair to the conversion advice: sometimes it is correct. If the child object has no meaningful existence without its parent — line items on a quote, inspection results on a property, allocations against a budget — then master-detail is describing something true. Cascade delete is the behavior you want. Inherited sharing is the behavior you want, because there is no scenario where someone should see the line and not the quote. In that case you were modeling it wrong before, and the roll-up field is a bonus for fixing it.

The tell is whether you can answer this without hedging: if the parent record is deleted, should every child disappear with it? If the answer is an immediate yes, convert the relationship and take the free field. If the answer starts with “well, usually, but there was that one time” — that hesitation is the org telling you the objects are independent, and you should not trade a true data model for a Setup screen. The failure mode isn’t the conversion itself, it’s converting for the field and discovering the ownership consequences a quarter later, when unwinding it means touching sharing rules, page layouts, and every automation that assumed an owner on the child.

Most requests I see fail that test. The objects are genuinely peers, related but independent, and the roll-up is a reporting convenience layered on top — which means it should be built as one.

What you’d build if the build were cheap

Strip away the scheduling problem and ask what you’d actually want. Almost always it is a small, purpose-built roll-up that does exactly your thing:

• A field, not a report. A currency, number, or date field on the parent, updated when the children change, usable in list views, formulas, alerts, and assignment rules.
• Your definition of “counts.” Standard roll-up summary filters are limited to simple criteria on the child. Your real definition is usually messier — open opportunities excluding a certain record type, invoices where status isn’t Void and the due date has passed, activity from the last ninety days only. Custom logic has no opinion about how complicated your definition is.
• Correct on bulk and on reparenting. Written once, tested against a data load, and not quietly wrong the first time someone runs an import.
• A backfill. The reason roll-ups feel scary is the existing data. A one-time recalculation across the current records, run in the sandbox first, gets you a field that is right on day one instead of right going forward.

That is maybe an afternoon of work for someone who knows the platform. It has never been an afternoon of availability, which is the whole problem.

The queue is the bottleneck, not the platform

Here is the position this post is taking: the roll-up you can’t have is not a Salesforce limitation you should re-architect your data model around. It is a small piece of development sitting in a queue that has no room for small pieces of development. Every org has a version of this list — the report nobody can assemble, the routing rule that ignores real territories, the custom object the process actually needs. They are all the same size, and they are all still open for the same reason.

What changes the calculus is not a better wizard. It is whether a request that size can be executed the week it’s asked for. When hiring or renting a developer is the only path, four-hour jobs never clear, because nobody engages a contractor for four hours. So they get postponed into spreadsheets and pivot tables, permanently.

Describe the number, get the field

This is what Sentinel is for. Your AI connects directly to your org — reads the schema, sees the relationship, writes the trigger and its tests, deploys it — so a roll-up request becomes a conversation instead of a ticket. You describe the number in your own words: total of open invoices on the account, excluding voided ones, kept current when invoices change or move. The AI reads the objects, queries what it needs to understand the data, builds the thing, and deploys it to a sandbox with tests before it goes anywhere near production.

The reason that’s a reasonable thing to do rather than a reckless one is accountability, not restriction: every action is logged, snapshots are taken before deploys, and Salesforce deploys are sandbox-first with tests required. To be explicit — Sentinel does not prevent your AI from shipping a roll-up that computes the wrong number. It makes the change visible in the log and the previous state recoverable. That’s the trade, and it’s the honest one. Connecting your org is a one-time setup.

Pricing is $2,500 one-time onboarding on your first Sentinel, plus $500/month per Sentinel.

Start with the number someone exports every week

There’s a good chance you already know which one it is. Somebody on your team has a recurring calendar block to build it by hand, or a saved report they re-pivot every Monday. That’s the roll-up. It doesn’t need a data model conversation, a package evaluation, or a place in next quarter’s roadmap — it needs an afternoon that nobody has.

Give your AI the hands to spend that afternoon for you. Set up your Sentinel — onboarding included.