3.3 Many-to-Many Relationships & Junction Objects

Many-to-Many Relationships & Junction Objects

In relational database modeling, a many-to-many relationship cannot be achieved by placing a single foreign key on either parent table. For example, consider an enterprise recruiting system:

• A single Job Position receives applications from hundreds of Candidates.
• A single Candidate can apply to multiple Job Positions simultaneously.

To connect these two entities without duplicating candidate profiles or position details, an architect creates a custom junction object: Job_Application__c. Each application record links exactly one Candidate to exactly one Position, while storing unique contextual metadata such as application date, interview feedback, and salary requirements.

+-------------------+              +-------------------------+              +-------------------+
|    Position__c    | 1          * |   Job_Application__c    | *          1 |   Candidate__c    |
|   (Master A)      |--------------|    (Junction Object)    |--------------|   (Master B)      |
+-------------------+  Master-     +-------------------------+  Master-     +-------------------+
                       Detail 1                                 Detail 2

---

Primary Master vs. Secondary Master Architecture

A junction object contains two master-detail relationships. Because custom objects can support a maximum of two master-details, the junction object is fully saturated. Salesforce establishes a hierarchy between these two parents based on creation chronology:

• Primary Master: The parent object linked by the first master-detail relationship created on the junction object.
• Secondary Master: The parent object linked by the second master-detail relationship created on the junction object.

Architectural Distinctions Between Masters

Although both master objects function as parents, the Primary Master holds special structural authority over the junction object:

1. Record Ownership and Look-and-Feel:
   • The junction object inherits its record ownership directly from the Primary Master.
   • Visual styling, including the custom object's default icon, theme color, and tab identity, is inherited from the Primary Master.
2. Related List Default Placement:
   • When detail records appear in related lists, the Primary Master's page layout displays the junction records with the secondary master's name as a prominent column by default, and vice versa.
3. Schema Change versus Record Deletion:
   • Deleting an individual master record cascade-deletes its junction records; it never changes which relationship is primary.
   • Deleting the primary master-detail relationship field, or converting it to a lookup, makes the secondary relationship primary. This is a metadata change, subject to dependency restrictions.

---

Cascade Deletion Mechanics in Many-to-Many Relationships

Because a junction record is a detail record in two distinct master-detail relationships, its lifecycle is strictly tied to both parents:

• Deleting Either Master: If either master record is deleted (whether Position or Candidate), Salesforce automatically executes a cascade delete on all related junction records (Job_Application__c). The junction records are placed in the Recycle Bin.
• Undeleting a Master: If the deleted master record is restored from the Recycle Bin, the junction records are restored automatically—provided the other master record was never deleted in the interim.
• Deleting Both Masters: If both master records are deleted independently, the junction record is deleted. In this scenario, the junction record is permanently deleted and cannot be restored.

---

Security, Permissions, and Access Requirements

Security enforcement on junction objects combines the permission structures of both master objects. App builders must remember this compound security model for exam scenarios:

+-----------------------------------------------------------------------------------+
|                         JUNCTION OBJECT ACCESS PERMISSIONS                        |
+-----------------------------------------------------------------------------------+
|  TO VIEW A JUNCTION RECORD:                                                       |
|  User must possess at least READ access on BOTH master objects.                   |
|  (Read on Master A  AND  Read on Master B)                                        |
+-----------------------------------------------------------------------------------+
|  TO CREATE, EDIT, OR DELETE A JUNCTION RECORD:                                    |
|  With Read/Write sharing settings on both relationships, user needs Read/Write on both master records and corresponding junction-object permissions.             |
|  (Both relationship minimums and junction object permissions must be met)                            |
+-----------------------------------------------------------------------------------+

If both relationships require Read/Write access and a user has Read/Write access to Position but only Read access to Candidate, they will be able to see existing Job_Application__c records, but they will be blocked from creating new applications or editing existing ones.

---

Roll-Up Summaries on Both Master Objects

A major architectural benefit of using two Master-Detail relationships (rather than two Lookups) is that both master objects can support Roll-Up Summary fields calculated from the junction object:

• On the Position__c object, an app builder can build:
  • A COUNT roll-up calculating total applicants.
  • A MIN roll-up displaying the lowest requested salary among applicants.
  • A MAX roll-up displaying the highest years of experience.
• On the Candidate__c object, the app builder can build:
  • A COUNT roll-up calculating total active applications submitted.
  • A filtered COUNT roll-up calculating applications in "Interview Scheduled" status.

Best Practices for Designing Junction Objects

1. Auto-Number Naming: Configure the Record Name field as an Auto-Number (e.g., APP-{00000}) rather than Text, since users should not have to invent artificial names for relational bridge records.
2. Store Associative Metadata: Use custom fields on the junction object to store information unique to the relationship itself (e.g., Interview_Score__c, Application_Date__c, Status__c), rather than placing these fields on either parent.
3. Do Not Exceed Two Master-Details: Salesforce strictly limits every custom object to two master-detail relationships. If a business requirement demands linking three or more entities simultaneously (e.g., Project, Employee, and Client), the third relationship must be implemented as a Lookup relationship.

Official Source Check

Checked October 19, 2026: Relationship and junction deletion considerations.