Salesforce Basics: Master-Detail vs Lookup in Salesforce

💬 In plain words: Master-Detail is a parent-child bond: child dies with the parent, inherits its sharing, and enables roll-up summaries. Lookup is a loose reference: both records live independently. Choose Master-Detail when the child has no meaning alone; choose Lookup when it does.

📌 Example: Invoice Line without an Invoice is meaningless → Master-Detail: delete the invoice, lines go too, and 'Invoice Total' is a free roll-up. Contact to 'Preferred Hotel' → Lookup: hotel deleted, contact lives on.

🎬 Real-Life Example: The Roll-Up That Cost a Sprint

Every Route__c screen must show how many Delivery__c records it carries. Simple total. Live at all times.

The Old/Bad Way: The team built Route–Delivery as a Lookup. Lookups have no native roll-up summary fields. So they wrote a trigger: count children on insert, subtract on delete, recount on reparent, handle undelete, handle bulk loads.

Why this is bad: You are rebuilding, by hand, a feature the platform gives away free. Every missed edge case leaves a wrong total on a manager's screen, destroying user trust fast.

The New/Good Way:

1. Ask the real question first: Is a Delivery meaningless without its Route? Yes. Should deleting a Route delete its Deliveries? Yes.
2. Master-Detail is the honest answer.
3. Add a Roll-Up Summary field: COUNT of Deliveries. The platform keeps it correct through delete, undelete, and reparenting automatically.

The payoff: Pick the relationship for the behavior you need — ownership, cascade delete, roll-ups — not for the line on the diagram.

Concept

Master-Detail (MD) makes the child depend on the parent. The child inherits the parent's owner and sharing. Delete the parent and the child goes with it. You also gain native Roll-Up Summary fields on the master: COUNT, SUM, MIN, MAX.

A Lookup is a loose reference. The child keeps its own ownership and sharing rules. The field can be optional, there is no cascade delete (unless configured via lookup filter behaviors), and there are no native roll-ups. This structural choice drives your sharing design, roll-up strategy, and deletion behavior.

🧠 Pick MD when: child is dependent, shares parent's security, needs roll-ups. Pick Lookup when: independent life, own sharing, optional link.

🧭 360 Card — Master-Detail vs Lookup

Rule: Master-Detail when the child cannot exist alone. Lookup when it can.

Gain: Cascade delete, roll-up summary fields, inherited owner/sharing, and required parent. Four capabilities, out of the box.

Price: Tighter coupling. The child gives up its own independent owner, sharing model, and lifecycle.

Limits: Maximum 2 Master-Detail relationships per child object. Reparenting is disabled by default. Up to 25 roll-up summary fields per parent object. Maximum 40 lookup fields per object.

Mirror — Lookup: Optional link, independent owner, independent sharing, no native roll-ups, no cascade delete.

Later: Junction objects require both Master-Detail slots. Spending one unnecessarily here prevents many-to-many designs later.

At volume: Every child save locks the parent record. Ten thousand children under one parent creates record locking skew, causing save operations to queue.

Core Q&A

Q: How do you decide between Master-Detail and Lookup for a new relationship?

🎯 Say this first: Master-Detail if the child can't exist alone and should inherit parent sharing (and you want roll-ups); Lookup for everything looser.

A: Evaluate three core criteria:

• 1. Lifecycle Dependency: Does the child record mean anything without the parent? If no, choose Master-Detail.
• 2. Security & Sharing: Should the child's visibility strictly track the parent's? Master-Detail inherits parent sharing completely. If the child requires its own Org-Wide Defaults (OWD) and sharing rules, use a Lookup.
• 3. Roll-Up Summaries: Do you need native declarative roll-up summary fields? Native Roll-Up Summaries require Master-Detail. With a Lookup, you must rely on Flow, Apex, or DLRS.
• System Limits: An object can have at most 2 Master-Detail relationships, and child objects in an MD chain cannot exceed maximum depth limits.

Follow-ups (Scenario-Based)

Q1: You need to convert an existing Lookup to Master-Detail on an object with 2M records. What are the preconditions and the risks?

A1: Two critical conditions must be met prior to conversion:

• Every child record must have a populated, non-null parent reference (no orphaned records allowed).
• You must accept that independent child record ownership is completely discarded. Children inherit the parent's owner and sharing rules, breaking any existing owner-based reports, sharing rules, or assignment logic on the child object.
• At 2M records, background sharing recalculation is heavy. Plan it as a maintenance migration off-hours using deferred sharing maintenance. Check parent roll-up limits before promising roll-up capabilities (capped at 25 roll-up summary fields).

Q2: A child object needs roll-ups on the parent, but also needs independent sharing. What are your options?

A2: Retain the Lookup relationship so the child preserves its independent sharing model, then implement roll-ups using alternative architectures:

• Record-Triggered After-Save Flow: Ideal for low-volume or simple count/sum calculations.
• Apex Trigger Handler: Necessary for high-volume transactions requiring bulkified aggregate queries.
• Scheduled Batch Apex / Asynchronous Roll-ups: Suitable for high-contention objects where eventual consistency is acceptable.
• Architect Trade-off: Real-time trigger roll-ups consume SOQL and DML limits during saves, while scheduled batch roll-ups sacrifice instant data freshness to protect transaction speed.

Recommended Reading: Junction Objects & Schema Limits