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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
The master object that the detail record points to. Cannot be changed once the field is saved.
The API name used in SOQL relationship queries, for example Order.Line_Items__r. Avoid renaming once Apex, formulas, or reports depend on it.
Controls whether edit access on the master implies edit access on the detail. Read/Write is the standard pick.
- 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.