Study guide
3.3 Many-to-Many Relationships & Junction Objects
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
3.3 Many-to-Many Relationships & Junction Objects
Key Takeaways Explain This Topic AI
Many-to-Many relationships are modeled using a custom junction object containing two separate Master-Detail relationships pointing to two parent objects.
The Primary Master is established by the first master-detail relationship created on the junction object, controlling the junction record's visual styling, tab colors, and ownership.
Deleting or converting the primary master-detail relationship field makes the secondary relationship primary. Deleting an individual master record instead cascade-deletes its junction records.
Junction access depends on both parent records, both relationship Sharing Settings, and the user's junction-object permissions; Read/Write on both parents is required when both relationships use that setting.
Deleting either parent master record causes the junction record to be cascade-deleted automatically into the Recycle Bin.
Last updated: October 2026
Many-to-Many Relationships & Junction Objects
Important
When business data requires that multiple records of Object A associate with multiple records of Object B, standard one-to-many relationships are insufficient. Salesforce models many-to-many relationships through a custom Junction Object containing two Master-Detail relationships.
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:
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.
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.
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.
- Feature Primary Master Secondary Master
- Relationship Order 1st Master-Detail relationship created 2nd Master-Detail relationship created
- Ownership Inheritance Junction record inherits owner from Primary Does not govern record ownership
- Visual Identity Dictates junction tab color and icon Does not affect visual theme
Relationship field deleted/converted Secondary relationship becomes primary Remaining primary relationship retains its role
- Cascade Deletion Deleting primary master deletes junction Deleting secondary master deletes junction
- Roll-Up Summary Fully supports roll-up summaries Fully supports roll-up summaries
- 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.
Note
Deleting one master record deletes the junction record, but has zero impact on the opposite master record . For example, deleting a Position deletes its related Job Applications, but the Candidate records remain completely untouched in the database.
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
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.
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.
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 .