Relationship Design: Master-Detail vs. Lookup, Junctions, and Roll-Ups
In Salesforce (and most CRMs), your relationship design defines how records connect and behave. The big three to know: Master-Detail, Lookup, and Junction objects for many-to-many. Roll-ups—native or custom—sit on top to summarize child data.
Master-Detail Relationship ?️
A tight parent-child link where the parent controls the child.
-
Parental control: The master dictates the detail record’s lifecycle and behavior.
-
Cascading delete: Delete the master, and all detail records go with it.
-
Inherited security: Detail records take on ownership and sharing from the master—no separate permissions.
-
Required link: The detail’s relationship field must be populated.
-
Native roll-ups: Only Master-Detail supports point-and-click Roll-Up Summary fields (COUNT, SUM, MIN, MAX).
-
Limits: Each object can be master in a limited number of Master-Detail relationships (typically two).
When to use: Child records shouldn’t exist without the parent, and you want built-in roll-ups and unified security.
Lookup Relationship ?
A looser link between independent objects.
-
Independence: Each record has its own owner and sharing.
-
No cascade by default: Deleting one record doesn’t delete the other; the lookup is usually cleared.
-
Separate security: Fine-grained control per object.
-
Optional link: The relationship field can be left blank (configurable).
-
No native roll-ups: Use automation (Flow or Apex) for roll-ups.
-
High limits: You can add many lookup fields (e.g., up to ~40).
When to use: Records can stand alone, need separate security, or the relationship is optional.
Junction Object (Many-to-Many) ?
A pattern (not a field type) that connects two objects many-to-many via a third object.
-
The bridge: Create a custom object that sits between the two (e.g., Enrollment between Student and Course).
-
Core structure: The junction has two Master-Detail fields—one to each parent—making it a child of both.
-
Relationship attributes: Store data about the link itself (e.g., Grade, Semester on Enrollment).
-
Outcome: One student ↔ many courses, one course ↔ many students—clean and scalable.
When to use: You need a true many-to-many with its own fields and behavior.
Roll-Up Summaries (Native vs. Custom) ?
Roll-ups aggregate child data and surface it on the parent.
Native Roll-Ups
-
Where: Only on Master-Detail.
-
Setup: Declarative (no code).
-
Functions: COUNT, SUM, MIN, MAX.
-
Behavior: Efficient; recalculates automatically on child changes.
-
Example: University roll-up counts related Department records.
Custom Roll-Ups
-
Where: Needed for Lookup relationships.
-
Setup: Automation (Flow, DLRS-style approaches, or Apex).
-
Flexibility: Go beyond the basic four—AVERAGE, conditional logic, concatenations, etc.
-
Trade-offs: More resource-intensive; accuracy depends on your automation firing on create/update/delete.
-
Example: Department calculates average Professor salary via a lookup.
Quick decision guide
-
Need the child to rely on the parent, share security, and support native roll-ups? → Master-Detail
-
Need independence, optional linking, or separate sharing rules? → Lookup
-
Need many-to-many with its own fields? → Junction (two Master-Detail fields)
-
On a Lookup but still need roll-ups? → Custom roll-ups via Flow or Apex
