3.2 Master-Detail & Lookup Relationships
Key Takeaways
Master-Detail relationships represent tightly coupled parent-child hierarchies where the detail record strictly inherits security, ownership, and sharing settings from the master record.
Deleting a master record initiates an automatic cascade delete of all associated detail records into the Recycle Bin, and restoring the master restores all related children.
Master-Detail relationships enable Roll-Up Summary fields on the master object, but each custom object is limited to a maximum of 2 Master-Detail relationships.
Converting a Master-Detail to a Lookup relationship requires deleting all roll-up summary fields on the master first, whereas converting a Lookup to Master-Detail requires populating the lookup field on every existing record.
Lookup relationships are loosely coupled with independent record ownership, customizable deletion behaviors ('Clear the value', 'Don't allow deletion', or support-enabled cascade), and optional or required Lookup Filters.
Master-Detail & Lookup Relationships
Important
The choice between a Master-Detail relationship and a Lookup relationship is one of the most critical design decisions on the Platform App Builder exam. It dictates record-level security architecture, ownership rules, cascade deletion behavior, and analytical roll-up capabilities.
Relational databases link tables through foreign key constraints. In Salesforce, these linkages are modeled declaratively using relationship field types. The two primary relationship paradigms are Master-Detail Relationships (tight coupling) and Lookup Relationships (loose coupling).
Master-Detail Relationships: Tightly Coupled Architecture
A Master-Detail relationship creates an intimate, parent-child dependency between two objects where the detail (child) record cannot exist independently of the master (parent) record.
1. Security and Ownership Inheritance
- No Independent Owner: Detail records do not have an
Ownerfield. Instead, ownership is inherited directly from the master record. Whatever user or queue owns the master record effectively controls the detail record. - Inherited Sharing: Detail records do not possess independent Organization-Wide Defaults (OWD), sharing rules, or manual sharing options. A user's access to detail records is determined entirely by their access to the parent master record:
- If the relationship's sharing setting is configured as Read-Only, users with at least Read access to the master can create, edit, or delete detail records, provided they have the corresponding object permissions.
- If configured as Read/Write, users need Read/Write access to the master to create, edit, or delete detail records, as well as the corresponding detail-object permissions.
- Mandatory Parent Field: The master-detail relationship field is strictly required on the detail record's page layout and data model. A detail record cannot be created or saved without referencing an active master record.
2. Cascade Delete and Restore Mechanics
- Cascade Delete: When a master record is deleted, Salesforce automatically cascade-deletes all associated detail records. The entire hierarchy moves into the Recycle Bin together.
- Cascade Restore: If the master record is undeleted from the Recycle Bin, all related detail records that were cascade-deleted are automatically restored with their previous linkages intact.
3. Roll-Up Summary Fields
- A supported master-detail relationship and available field allocation are prerequisites for creating Roll-Up Summary Fields on the master object.
- Roll-up summary fields calculate values from child detail records to display aggregates on the master record. Supported operations include:
COUNT: Total number of related detail records.SUM: Cumulative sum of a numeric, currency, or percent field on detail records.MIN: Minimum value among detail records (supports numbers, currencies, percents, and dates).MAX: Maximum value among detail records.
- Each custom object can support up to 25 roll-up summary fields (or up to 40 via a Salesforce Support limit increase request).
4. Architectural Limits and Constraints
- Maximum 2 Master-Details: A custom object can have a maximum of two (2) Master-Detail relationships.
- Standard Object Limitations: A standard object can serve as the Master in a relationship with a custom detail object. However, a standard object cannot be on the Detail side of a master-detail relationship with a custom object.
- Reparenting Controls: By default, once a detail record is created and linked to a master, it cannot be reparented to a different master record. To allow users to reassign detail records to a new master, an app builder must explicitly check the "Allow Reparenting" checkbox on the master-detail relationship definition.
Relationship Conversions: Lookup vs. Master-Detail
Business requirements often evolve, requiring administrators to convert relationship fields between Lookup and Master-Detail types. The platform enforces strict preconditions before allowing these conversions:
+-----------------------------------------------------------------------------------+
| RELATIONSHIP CONVERSION RULES |
+-----------------------------------------------------------------------------------+
| LOOKUP =======> MASTER-DETAIL |
| Allowed ONLY IF the lookup field is currently populated on EVERY existing |
| record in the database. (No null values permitted). |
+-----------------------------------------------------------------------------------+
| MASTER-DETAIL =======> LOOKUP |
| Allowed ONLY IF NO Roll-Up Summary fields exist on the master object that |
| reference the detail object. (All roll-up summaries must be deleted first). |
+-----------------------------------------------------------------------------------+
Note
If an administrator attempts to convert a Master-Detail relationship to a Lookup while a roll-up summary field is still present on the master object, the conversion will be blocked. Even if the roll-up field is deleted, it must be permanently erased from the "Deleted Fields" recycle bin before Salesforce permits the relationship conversion.
Lookup Relationships: Loosely Coupled Architecture
A Lookup relationship links two objects together while maintaining operational independence between them. Common examples include associating an Account with a primary Contact, or linking a Case to an Asset.
1. Independent Ownership and Security
- Independent Owner: Child records retain their own distinct
Ownerfield (user or queue). - Independent Sharing: Child records follow their own Organization-Wide Defaults, role hierarchy grants, sharing rules, and manual shares, completely decoupled from the parent record's security posture.
- Optional by Default: The lookup field is optional by default, meaning child records can exist without referencing a parent (orphan records are permitted).
2. Lookup Deletion Options
When a parent record in a lookup relationship is deleted, an app builder can configure one of three declarative behaviors:
- Clear the value of this field: Sets the lookup field on child records to blank/null. This is the default behavior. (Cannot be selected if the lookup field is marked as universally required).
- Don't allow deletion of the lookup record that's part of a lookup relationship: Prevents deletion of the parent record as long as child records still reference it. This protects referential integrity and prevents orphaned operational data.
- Delete this record also (Cascade Delete): Cascade deletes the child record when the lookup parent is deleted. This behavior is standard on certain system relationships (such as Account to Contact), but for custom lookup relationships, it is disabled by default and requires contacting Salesforce Support to activate under strict business justifications.
3. Lookup Filters
Lookup filters restrict the subset of valid records available for selection in a lookup search dialog. Filters compare fields on the target object against fields on the source record, current user record, or user profile.
- Required Lookup Filter: Strictly enforced by the platform. If a user enters or selects a record that does not satisfy the filter criteria, Salesforce displays an error message and prevents saving. Enforced across UI and API operations.
- Optional Lookup Filter: Acts as a user guidance mechanism. When the user opens the lookup search window, only records meeting the criteria are displayed initially. However, the user can click "Show all results" to clear the filter and select any record in the target object.
Master-Detail vs. Lookup Comparison
| Architectural Attribute | Master-Detail Relationship | Lookup Relationship |
|---|---|---|
| Coupling Level | Tightly coupled parent-child dependency | Loosely coupled independent link |
| Relationship Required? | Strictly required on detail record | Optional by default; can be made required |
| Record Ownership | Child inherits master record owner | Child has its own independent owner |
| Security & Sharing | Inherited from master (Read or Read/Write) | Independent OWD, sharing rules, and grants |
| Parent Deletion Impact | Automatic cascade delete of detail records | Clear value, block deletion, or cascade (support) |
| Roll-Up Summary Support | Fully supported on master object | Not supported (requires Flow or Apex) |
| Relationship Limits | Maximum 2 per custom object | 40 relationship fields by default, including master-detail |
| Standard Object Detail? | Standard objects cannot be custom details | Standard objects can be custom lookup children |
| Reparenting Allowed? | Blocked by default; enabled via checkbox | Always permitted unless validation blocks it |
Official Source Check
Checked October 19, 2026: Master-detail sharing requirements.
Universal Containers tracks customer warranty claims on a custom Claim__c object linked to Account via a lookup relationship. Leadership wants to convert this relationship into a Master-Detail relationship so that total claim payout amounts can be calculated using a Roll-Up Summary field on Account. When the app builder attempts to change the field type in Object Manager, an error occurs. What is the most likely cause of this issue?
Account is a standard object, and standard objects cannot serve as the Master in a Master-Detail relationship.
The Account object has already reached the maximum limit of two Master-Detail relationships.
Roll-up summary fields must be created on the Account object before converting the lookup relationship.
Existing Claim__c records exist in the org where the Account lookup field is not populated.
Projects link to Milestone__c through a custom lookup. A project must not be deleted while any Milestone references it. Which field setting enforces this without code?
Select 'Don't allow deletion of the lookup record that's part of a lookup relationship' on the lookup field definition.
Write a record-triggered Flow on Project__c that fires before delete to inspect child Milestones.
Configure the lookup field deletion option to 'Clear the value of this field' and make the field required on page layouts.
Convert the lookup relationship into a Master-Detail relationship to prevent master deletion.
Cloud Kicks uses a Master-Detail relationship between Order__c (Master) and Order_Item__c (Detail). A sales manager requests that specific sales reps be granted Read-Only access to Order__c records while retaining the ability to edit related Order_Item__c records. How can an app builder fulfill this requirement?
Set the relationship Sharing Setting to Read Only and grant the required Order_Item__c object permissions.
Inform the manager that Read access to a master can never permit editing details.
Set Order_Item__c OWD to Public Read/Write.
Create an independent sharing rule on Order_Item__c.
Sections you finish are checked off in the contents.