6.2 Object Relationships: Lookup, Master-Detail & Junctions

Object Relationships: Lookup, Master-Detail & Junctions

Quick Summary: In relational databases, entities are linked through foreign keys and join tables. Salesforce delivers relational data modeling declaratively through relationship fields. Understanding the architectural differences between loosely coupled Lookup relationships and tightly coupled Master-Detail relationships—including deletion cascading, security inheritance, roll-up capability, and junction object implementations—is a cornerstone of the Salesforce platform data model.

Relational Data Modeling in Salesforce

In enterprise operations, business entities do not exist in isolation. A customer account relates to multiple contacts; a sales opportunity connects to specific products; a hospital patient relates to doctors, appointments, and medical charts. In traditional relational database systems (RDBMS), architects create primary keys, foreign keys, and complex SQL joins to connect tables.

In Salesforce, administrators establish relational connections declaratively by creating Relationship Fields. When a relationship field is added to an object, the platform automatically:

• Adds a lookup search dialog widget to the child record's edit page so users can select a parent record.
• Generates a Related List on the parent record's page layout, displaying all associated child records.
• Enables cross-object reporting, allowing users to build reports spanning multiple related objects.

The Salesforce platform provides three primary relationship types: Lookup Relationships, Master-Detail Relationships, and specialized Hierarchical Relationships.

---

Lookup Relationships: Loose Coupling

A Lookup Relationship creates a flexible, loosely coupled connection between two objects. It can link standard objects to standard objects, standard objects to custom objects, or custom objects to each other.

+-------------------------------------------------------------------------+
| LOOKUP RELATIONSHIP (Loose Coupling)                                    |
|                                                                         |
|   [Parent Record: Account]  <--- optional link ---  [Child Record: Asset]|
|                                                                         |
| - Child record exists independently with or without a parent            |
| - Child has its own OwnerId and independent security/sharing            |
| - Deleting Parent does NOT delete Child (clears lookup or blocks delete)|
| - Does NOT support Roll-Up Summary fields on Parent                     |
| - Up to 40 Lookup relationships per object                              |
+-------------------------------------------------------------------------+

Key Architectural Characteristics of Lookup Relationships

1. Independent Existence: Child records can exist independently without being linked to a parent record. While administrators can make the lookup field required on page layouts or field definitions, the underlying relationship architecture is fundamentally optional.
2. Independent Ownership and Security: The child record retains its own OwnerId field. Sharing rules, Organization-Wide Defaults, and role hierarchy settings apply to the child record independently from the parent. A user might have permission to edit the child record even if they only have read access to the parent.
3. Configurable Deletion Behaviors: When an administrator deletes a parent record referenced by a lookup field, child records are not deleted by default. During lookup field setup, the administrator selects one of three deletion behaviors:
   • Clear the value of this field (Default): The platform deletes the parent record and automatically sets the lookup field on all related child records to blank (null).
   • Don't allow deletion of the lookup record that's part of a lookup relationship: Prevents the parent record from being deleted as long as active child records are linked to it.
   • Delete this record also (Cascade Delete): Available only in specialized standard relationships or via Salesforce customer support enablement for specific custom scenarios.
4. Roll-Up Summary Limitation: Standard Lookup relationships do not support native Roll-Up Summary fields on the parent object. (Calculating aggregates across lookup relationships requires Flow automation, Apex triggers, or AppExchange tools).
5. Object Limits: An object can contain up to 40 lookup relationships, providing broad flexibility for cross-referencing records.

---

Master-Detail Relationships: Tight Coupling

A Master-Detail Relationship establishes a highly structured, tightly coupled parent-child hierarchy between two objects. In this architecture, the child entity (the Detail) is completely dependent upon the parent entity (the Master) for its existence, security, and lifecycle.

+-------------------------------------------------------------------------+
| MASTER-DETAIL RELATIONSHIP (Tight Coupling)                             |
|                                                                         |
|   [Master: Invoice__c]  <=== strictly required ===  [Detail: Line_Item__c]|
|                                                                         |
| - Detail record CANNOT exist without a Master record                    |
| - Detail has NO OwnerId; strictly inherits Master's sharing & security  |
| - Deleting Master CASCADE DELETES all related Detail records            |
| - Undeleting Master restores all related Detail records                 |
| - Enables Roll-Up Summary fields on Master (COUNT, SUM, MIN, MAX)       |
| - Maximum of 2 Master-Detail relationships per custom object            |
+-------------------------------------------------------------------------+

Key Architectural Characteristics of Master-Detail Relationships

1. Mandatory Master Link: The relationship field on the detail record is always required. A detail record cannot be created or saved without specifying a valid master record.
2. Cascade Deletion: The lifecycle of the detail record is bound to the master. If a master record is deleted, Salesforce automatically cascade-deletes all associated detail records. If the master record is subsequently recovered from the Recycle Bin, all related detail records are restored automatically.
3. Security and Sharing Inheritance: Detail records do not have an independent OwnerId field and do not have their own Organization-Wide Defaults or sharing rules. Instead, detail records inherit the exact sharing and security model of their master record. The Master-Detail relationship definition includes a sharing setting specifying whether users need Read Only or Read/Write access on the master record to create, edit, or delete detail records.
4. Roll-Up Summary Fields: Master objects natively support Roll-Up Summary fields. An administrator can create up to 25 roll-up summary fields on the master object to aggregate numeric or currency values from child detail records using COUNT, SUM, MIN, or MAX.
5. Relationship Limits: A custom object can possess a maximum of 2 Master-Detail relationships.
6. Re-Parenting Behavior: By default, once a detail record is created and linked to a master, it cannot be transferred to a different master record. If the business requires reassigning detail records (e.g., transferring a project milestone to a different project), the administrator must explicitly check the Allow reparenting checkbox in the Master-Detail relationship field definition.

Converting Between Lookup and Master-Detail Relationships

Exam questions frequently test the rules for converting between relationship types:

• Converting Lookup to Master-Detail: You cannot directly create a Master-Detail relationship on a custom object if records already exist on that object, because existing records would have empty parent fields. To establish a Master-Detail relationship on an object populated with data:
  1. Create the relationship as a standard Lookup.
  2. Populate the lookup field with a valid parent record on every single existing record.
  3. Edit the field definition and change the field type from Lookup to Master-Detail.
• Converting Master-Detail to Lookup: A Master-Detail relationship can be converted to a Lookup relationship only if the master object does not currently contain any Roll-Up Summary fields referencing the detail object. If roll-up summaries exist, they must be deleted before conversion.

---

Many-to-Many Relationships & Junction Objects

In business modeling, many scenarios require a Many-to-Many (N:N) relationship, where:

• One record of Object A can link to multiple records of Object B, AND
• One record of Object B can link to multiple records of Object A.

Classic Real-World Examples

• Education: A Student enrolls in multiple Courses, and each Course contains multiple Students.
• Recruiting: A Job Candidate applies for multiple Positions, and each Position receives applications from multiple Job Candidates.
• Real Estate: A Property possesses multiple Amenities (Pool, Gym, Garage), and each Amenity applies to multiple Properties.

+--------------------------------------------------------------------------+
|                       Many-to-Many Architecture                          |
|                                                                          |
|   [Master A: Candidate__c]          [Master B: Position__c]              |
|              \                          /                                |
|               \                        /                                 |
|          [Master-Detail 1]        [Master-Detail 2]                      |
|                 \                      /                                 |
|                  v                    v                                  |
|               +-------------------------------+                          |
|               | Junction Object:              |                          |
|               | Job_Application__c            |                          |
|               +-------------------------------+                          |
+--------------------------------------------------------------------------+

How to Build a Junction Object

A Many-to-Many relationship is implemented in Salesforce using a custom intermediary object called a Junction Object. The steps to implement a junction object are:

1. Create a custom object to act as the bridge (e.g., Job_Application__c or Course_Enrollment__c).
2. Create a Master-Detail relationship field on the junction object pointing to the first master object (e.g., Candidate__c). This becomes the Primary Master.
3. Create a second Master-Detail relationship field on the junction object pointing to the second master object (e.g., Position__c). This becomes the Secondary Master.

Primary vs. Secondary Master Rules

• Primary Master: The first master-detail relationship created determines the look-and-feel of the junction object record pages (such as tab color and icon) and determines the default record ownership context.
• Deletion Propagation: If a user deletes a record from either master object, the junction records linked to that master are automatically cascade-deleted. For example, deleting a Candidate automatically cascade-deletes all of their Job_Application__c records without deleting the related Position records.
• Related Lists: Both master objects display a Related List showing the junction records, giving users a complete bi-directional view of the relationship.

---

Hierarchical Relationships on the User Object

A Hierarchical Relationship is a specialized lookup relationship available exclusively on the standard User object.

• It allows linking one user account directly to another user account without referencing other objects.
• The primary use case is establishing organizational reporting structures (e.g., creating a Manager or Executive Approver lookup on the User record).
• Hierarchical relationships cannot be created on any object other than the User object.

---

Comparison: Lookup vs. Master-Detail Relationships