Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionaryMMaster-Detail Relationship
Core CRMIntermediate

Master-Detail Relationship

A master-detail relationship is a parent-child link between two Salesforce objects where the detail (child) record inherits sharing, ownership, and lifecycle from the master (parent).

§ 01

Definition

A master-detail relationship is a parent-child link between two Salesforce objects where the detail (child) record inherits sharing, ownership, and lifecycle from the master (parent). If the master is deleted, every detail record is deleted with it. Detail records cannot exist without a parent, and the parent reference cannot be left blank on creation.

That tight coupling is what separates master-detail from a lookup. Lookup is optional and loose. Master-detail is required and structural. The choice locks in roll-up summaries, cascade deletes, ownership inheritance, and the ability to build many-to-many junction objects. Once detail records exist, converting the relationship type gets restrictive, so the decision belongs at the design stage, not after data load.

§ 02

Why master-detail decisions shape the data model for years

Sharing and ownership inherit from the parent

Detail records have no owner field of their own. They take their owner, sharing rules, and role-hierarchy access from the master record. Anyone who can see or edit the parent inherits the same level on the child. This simplifies access design but removes a lever. You cannot share a single detail record with a different team than its parent. If you need independent sharing or ownership on the child, lookup is the right choice and master-detail will fight you the whole way.

Cascade delete and undelete behavior

Deleting the master deletes every detail record in one operation. The Recycle Bin keeps both for 15 days, and restoring the master brings back the children. Cascade delete fires before the master record commits its own delete, so detail-side Apex triggers execute first. This matters for audit logging and integrations that listen for delete events on the child object. Hard delete via the Bulk API skips the Recycle Bin entirely and is irreversible.

Roll-up summary fields on the master

Only master-detail enables roll-up summary fields. COUNT, SUM, MIN, and MAX aggregate values from detail records onto the master in real time, with optional filter criteria. Each parent object supports up to 40 roll-ups (25 by default, raise the limit through support). Roll-ups recalculate when detail records change, and large detail volumes (more than 10,000 children per master) can trigger CPU governor issues during batch loads. Lookup relationships do not support roll-ups natively, so teams fake them with scheduled Apex or DLRS.

Junction objects need exactly two master-detail relationships

A many-to-many relationship in Salesforce uses a junction object with two master-detail relationships, one to each side. The first master-detail you define becomes the primary master. Its sharing rules drive who can see the junction record, and its delete cascades fastest. The second master is secondary, and if it is deleted the junction record is deleted too, but recovery semantics differ between the two. Order of creation matters for the lifetime of the junction, so configure the more important parent first.

Conversion rules between lookup and master-detail

You can convert a lookup to master-detail only when every existing child record has a populated parent value with no orphans. Going from master-detail to lookup is allowed only when no roll-up summary fields exist on the parent and the conversion will not break sharing inheritance. After conversion, the owner field appears on the child and needs a default. Plan conversions during low-traffic windows because the platform rewrites sharing rows for every affected record, which can lock related tables for minutes.

Detail and subdetail chains

Salesforce allows a detail object to itself be the master of another object, creating a master-detail-detail chain sometimes called subdetail. The chain is capped at three levels of master-detail nesting. Owner and sharing still propagate from the top of the chain downward. Roll-ups can climb from subdetail to detail to master, but each level adds calculation cost and recalculation latency. Beyond three levels, switch to lookup with custom Apex or scheduled jobs.

Standard objects that behave like master-detail

OpportunityLineItem to Opportunity, CaseComment to Case, Quote to Opportunity, and similar standard pairings behave as master-detail relationships even though the relationship field appears as a system reference. You cannot change these or remove the cascade behavior. They explain why deleting an Opportunity wipes its line items without prompting. When you build custom equivalents on your own objects, follow the same pattern: required parent reference, cascade delete, and roll-ups on the master.

§ 03

How to set up a Master-Detail Relationship

Master-detail looks like a simple field type but the configuration choices lock in long-term behavior. Walk through these steps in a sandbox before touching production, and load data only after you confirm sharing and cascade settings match what the business expects.

  1. Confirm the parent-child semantics first

    Sketch the relationship on paper. If a child record makes no sense without a parent, master-detail fits. If the child can exist standalone, like an Account without a parent Account, use lookup. Discuss cascade delete with the data owner and the integration team before continuing.

  2. Create the relationship field on the detail object

    Go to Setup, Object Manager, pick the detail (child) object, then Fields and Relationships, New, Master-Detail Relationship. Choose the parent object. You cannot edit this object reference later, so confirm with the business owner before you save.

  3. Set the sharing setting

    Choose Read/Write if editing the master should let users edit the detail too, or Read Only if detail edits should require explicit access. Read/Write is the default and usually correct. Read Only is rare and tends to create confusion during sharing audits, so document the reason if you pick it.

  4. Decide whether the child allows reparenting

    Check Allow reparenting only if business rules permit moving a detail record to a different master after creation. Most invoices, line items, and audit records should not be reparented. Once enabled, the setting is hard to reverse without data cleanup, so default to off when in doubt.

  5. Add the field to page layouts and assign FLS

    The new field appears on the detail page layout automatically, but verify it shows in the right section. Set field-level security per profile or permission set. Profiles without read access see a blank parent column on related lists and report grouping breaks silently.

  6. Build roll-up summary fields on the master

    Go back to Setup, Object Manager, the master object, Fields and Relationships, New, Roll-Up Summary. Pick the detail object, the aggregate type (COUNT, SUM, MIN, MAX), and a filter if needed. Roll-ups recalculate immediately on the first save but back-fill in a batch for existing data, which can take hours on large volumes.

  7. Test cascade delete in sandbox

    Create a master record with a few detail children. Delete the master and confirm both vanish from list views and the Recycle Bin shows them. Restore the master and confirm the children come back together. Document this behavior in your runbook so support knows what to expect on accidental parent deletes.

Key options
Parent object reference (Related To)remember

The master object that the detail record points to. Cannot be changed once the field is saved.

Child Relationship Nameremember

The API name used in SOQL relationship queries, for example Order.Line_Items__r. Avoid renaming once Apex, formulas, or reports depend on it.

Sharing Setting (Read/Write or Read Only)remember

Controls whether edit access on the master implies edit access on the detail. Read/Write is the standard pick.

Gotchas
  • Master-detail fields are required at the record level. Bulk-loading detail rows without a populated parent ID fails the whole batch, not just the individual row, so validate inputs before the load.
  • Roll-up summary recalculations on very large parents (more than 10,000 children) can blow the CPU governor limit during data loads. Defer triggers, disable roll-ups during the load, or use Bulk API in sequential mode.
  • The first master-detail you add to a junction object becomes the primary master. Its sharing rules win, and its delete cascades fastest. Add the more security-sensitive parent first or accept the consequences.
  • Standard pairs like Opportunity to OpportunityLineItem behave as master-detail but the field is read-only and uneditable in Setup. You cannot remove the cascade or change the sharing model on these system relationships.
  • After you convert master-detail to lookup, the owner field appears blank on every child record. Set a default owner during conversion or Salesforce will assign the running user, which corrupts audit history.
§

Trust & references

Sources

Cross-checked against the following references.

Official documentation

Straight from the source - Salesforce's reference material on Master-Detail Relationship.

Keep learning

Hands-on resources to go deeper on Master-Detail Relationship.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.

§

Test your knowledge

Q1. What happens when Master-Detail Relationship data is not maintained properly in Salesforce?

Q2. Who would typically configure or interact with Master-Detail Relationship?

Q3. What best describes the purpose of Master-Detail Relationship in Salesforce?

§

Discussion

Loading…

Loading discussion…