Lesson 8 of 18 · 5–7 minutes

Lookup vs Master-Detail

Once entities are clear, decide how tightly their records should depend on each other. Junction objects build on this decision.

Learning sequence · data model first, security layers next

Your focus

Prepare for Your Next Developer Role

REVIEW · Review • Apply • Practice

Defend the onboarding choice and explain query, reporting and automation implications.

Learning objective

Choose a relationship using ownership, deletion, sharing and aggregation requirements.

Before you start

Objects, fields and records; distinguish an identifier from a display name.

Real-world scenario

An onboarding application has checklist items that should exist only with the application: master-detail may fit. A compliance review must survive closure or removal of its related application: consider a lookup with deletion restrictions and an explicit retention policy instead.

The concept

Lookup links records while generally preserving the child’s independent ownership and sharing. Requiredness and parent-delete behavior depend on the field and object settings. Master-detail requires a master, removes independent detail ownership, and ties record access to the parent. Deleting the master deletes its details. Native roll-up summaries on the master can aggregate details. Standard relationships have special behavior: do not use Account–Contact as a universal custom-object template.

Agree on retention and access before choosing convenience. Test deletion, reparenting and reporting in a sandbox. During migration, load required parents before their children. Relationship queries navigate the model; they do not reveal the configured relationship type.

Compare relationship choices

These are custom-object design choices; inspect standard-object exceptions.

1.Lookup
Independent child lifecycle; configure requiredness and deletion behavior.
2.Master-detail
Required parent; inherited ownership/access, cascade deletion and native roll-ups.

Lookup connects to Master-detail: Use the tighter dependency only when the business lifecycle supports it.

Parent-to-child: Accounts and their Contacts

soql

SELECT Id, Name,
    (SELECT Id, FirstName, LastName FROM Contacts)
FROM Account

Contacts is the child relationship name. The nested result contains the related Contact records.

Child-to-parent: Contact and Account

soql

SELECT Id, FirstName, LastName, Account.Name
FROM Contact

Account.Name follows the parent relationship. These examples illustrate traversal, not a master-detail configuration.

Common mistake

Choosing master-detail only to obtain a roll-up, without accepting inherited sharing or cascade deletion. A lookup does not automatically delete its children; inspect its configured behavior.

Interview angle

“Both options link records. Why choose one?” State whether the child needs its own owner, independent retention and record access; then explain the roll-up trade-off.

Pause and apply

For onboarding checklist items, write a deletion test and an access test. What changes if records must be retained independently for audit?

Official references

Reviewed 2026-09-22. Examples are illustrative; no code is executed here.

Key takeaways

Lifecycle and access requirements come before roll-ups.
Use dot notation from child to parent; a subquery returns children.
Model choice affects queries, automation, reporting and import order.

Practice next

Apply the child-to-parent query example; this checks navigation, not the full relationship design decision.

Debug the Contact-Account Relationship Query

Reading these lessons does not yet save completion. Challenge results continue to provide assessment evidence.