Junction Objects and Many-to-Many Relationships

Why This Topic Matters
Real business data is rarely one-to-many. A student enrolls in many courses and a course has many students. A job can require many skills and a skill applies to many jobs. A product can appear in many bundles and a bundle contains many products. Salesforce does not offer a native many-to-many field type, so administrators must design one using a junction object. On the Advanced Administrator exam this topic sits inside the Advanced Objects and Applications section, and questions test whether you can recognize when a many-to-many relationship is needed, how to build it correctly, and what consequences the design has for sharing, ownership, deletion, reporting, and roll-up summaries. Because junction objects combine several core concepts (master-detail behavior, cascade delete, record access, roll-ups), one question can test your understanding of all of them at once. Getting this topic right is high value.

What Is a Many-to-Many Relationship?
In a one-to-many relationship, one parent record relates to many child records, but each child has exactly one parent (one Account has many Contacts). In a many-to-many relationship, each record on either side can relate to many records on the other side. Salesforce models this by introducing a third object, the junction object, that sits between the two. Each junction record represents a single pairing: one record from Object A linked to one record from Object B. Many junction records together produce the many-to-many effect.

What Is a Junction Object?
A junction object is a custom object with two master-detail relationship fields, each pointing to a different master object. For example, to connect Job Posting and Skill you create a custom object called Job Skill with a master-detail to Job Posting and a master-detail to Skill. Every Job Skill record links one job to one skill. Salesforce itself uses this pattern with standard objects: Opportunity Contact Role (Opportunity to Contact), Campaign Member (Campaign to Lead or Contact), Opportunity Product (Opportunity to Price Book Entry), Price Book Entry (Price Book to Product), and Account Contact Relationship (Account to Contact when Contacts to Multiple Accounts is enabled). Recognizing these standard junctions helps you spot the pattern in exam scenarios.

How to Build a Junction Object
1. Create the custom object (for example, Job Skill). Give it a meaningful label, and consider using an auto-number record name so users do not have to type a name for each pairing.
2. Create the first master-detail relationship field to the first master object (for example, Job Posting). This becomes the primary master.
3. Create the second master-detail relationship field to the second master object (for example, Skill). This becomes the secondary master.
4. Add the junction object as a related list on the page layouts of both master objects so users can create pairings from either side.
5. Optionally add roll-up summary fields on either master to count or summarize junction records, and add any additional fields to the junction object that describe the relationship itself (such as Proficiency Level or Years Required).

Primary Versus Secondary Master: Why Order Matters
The first master-detail relationship you create is the primary master, and it controls several behaviors:
- Look and feel: The junction object detail and edit pages use the color and icon of the primary master object.
- Record ownership: Junction records inherit the Owner value from the primary master record. Detail records have no visible Owner field, so this only becomes relevant if both master-detail relationships are later removed.
- Division: If divisions are enabled, junction records inherit the division of the primary master.
If you delete the primary master-detail relationship or convert it to a lookup, the secondary master becomes the primary.

Sharing and Record Access on Junction Records
Because junction records are details of two masters, their access is determined by access to both master records combined with the Sharing Setting option chosen on each master-detail field (Read Only or Read/Write). The rules to remember:
- A user can view a junction record only if the user has at least Read access to both associated master records.
- To create, edit, or delete a junction record, the user must have the access level required by the Sharing Setting on each master-detail field. If both are set to Read/Write, the user needs Read/Write access on both master records. If a field is set to Read Only, Read access on that master is sufficient for that side.
- Junction objects built with master-detail fields have no Organization-Wide Default of their own (it is Controlled by Parent), cannot have their own sharing rules, and cannot be manually shared. Access always flows from the masters.

Deletion and Undelete Behavior
- Deleting either master record cascades and deletes the related junction records.
- If you undelete a master record from the Recycle Bin, its junction records are restored as well.
- If both master records are deleted, the junction record is deleted permanently and cannot be restored, even if one of the masters is later undeleted.
- Deleting a junction record never affects the master records.
- Users need delete permission on the junction object only indirectly; cascade delete runs even if the user does not have delete permission on the junction object.

Roll-Up Summary Fields
Because both relationships are master-detail, you can create roll-up summary fields on either master object that COUNT, SUM, MIN, or MAX fields from the junction records. For example, a Number of Skills Required roll-up on Job Posting and a Number of Open Jobs roll-up on Skill. This is a major reason to choose master-detail over lookup for a junction design. You cannot roll up through two levels (a master cannot summarize fields from the other master through the junction) without formula or automation workarounds; roll-ups summarize only the direct detail records.

Reporting Across a Junction Object
Standard report types are generated for the junction object with its masters (for example, Job Postings with Job Skills). To report on records from one master in relation to the other, create a custom report type with the primary master as the primary object, the junction object as the related object, and then add fields from the second master using the lookup field on the junction. Custom report types allow with or without logic so you can also find masters that have no junction records. The junction object fields are available directly in reports because the master-detail field acts like a lookup for field access.

Junction Object Limits and Constraints
- An object can have at most two master-detail relationships, which is exactly what makes a junction object.
- Standard objects cannot be on the detail side of a master-detail relationship, so the junction object must be a custom object, though its masters can be standard or custom.
- Master-detail fields are required on every junction record, so both parent values must be supplied when the record is created.
- Converting an existing lookup to master-detail requires that every existing record has a value in that lookup field.
- Junction objects cannot be the master in a further master-detail chain beyond the overall three-level custom object depth limit, so keep hierarchies shallow.
- Reparenting of detail records is allowed only if Allow reparenting is checked on the master-detail field.

Master-Detail Junction Versus Two Lookups
You can also link two objects with a custom object that uses two lookup fields. This is sometimes called a loose junction. Choose master-detail when you need cascade delete, roll-up summaries, inherited sharing, and a guaranteed required relationship. Choose lookups when junction records need their own Owner, their own Organization-Wide Default and sharing rules, the ability to exist when one parent is blank, or when one of the parents is a standard object that would be deleted frequently and you want the junction records to survive. Exam questions often describe requirements such as roll-ups or inherited security to signal master-detail, or independent ownership and sharing to signal lookups.

Common Business Scenarios the Exam Uses
- Students and Courses with an Enrollment junction object.
- Doctors and Patients with an Appointment or Visit junction.
- Products and Bundles with a Bundle Item junction.
- Volunteers and Events with a Shift Assignment junction.
- Contacts and Accounts using the standard Account Contact Relationship rather than a custom junction.
In each case the junction object also usually carries attributes about the relationship, such as Grade, Date, Quantity, or Role.

Exam Tips: Answering Questions on Junction Objects and Many-to-Many Relationships
1. Identify the signal words. Phrases like each X can have many Y and each Y can have many X, or can be associated with multiple, always point to a many-to-many relationship and therefore a junction object. If only one direction is many, a single lookup or master-detail is enough and a junction is the wrong answer.
2. Know the definition cold. A junction object is a custom object with two master-detail relationships. If an answer choice describes a standard object as the junction, or a custom object with one master-detail and one lookup as the correct definition, treat it carefully; it may be valid for a loose junction but not as the textbook definition.
3. Remember what the primary master controls. Look and feel, ownership, and division all come from the first master-detail relationship created. Questions asking why a junction record shows a particular icon or owner are testing this.
4. Apply the both masters rule for visibility. A user who cannot see one of the two master records cannot see the junction record. If a scenario says a user cannot view certain junction records, check their access to each master before considering profile permissions.
5. Apply the both masters rule for editing. To create or edit a junction record the user must meet the Sharing Setting requirement on each master-detail field. Read/Write on both masters is the safest assumption unless the field is set to Read Only.
6. Cascade delete is automatic. Deleting a master deletes junction records; undeleting a master restores them; deleting both masters makes the junction record unrecoverable. Expect at least one question on this sequence.
7. Roll-ups need master-detail. If the requirement includes counting or summing the related records on a parent, the answer must involve master-detail relationships, not lookups, unless the question offers flow or Apex as an alternative.
8. Junction objects do not have their own sharing model. Any answer offering sharing rules, manual sharing, or a unique OWD for a master-detail junction object is incorrect. Those options exist only when the junction uses lookup fields.
9. Reporting usually needs a custom report type. If the question asks how to report on records from one master grouped by the other, the right answer is typically a custom report type with the junction object as the related object, not a standard report type.
10. Prefer standard junctions when they exist. If a scenario asks to relate Contacts to multiple Accounts or Contacts to Opportunities, the answer is the standard feature (Contacts to Multiple Accounts, Opportunity Contact Roles), not a new custom junction. The exam rewards using built-in functionality.
11. Eliminate answers that violate limits. No object can have three master-detail relationships, standard objects cannot be details, and master-detail fields cannot be left blank. Use these constraints to discard distractors quickly.
12. Read for the extra attribute. If the scenario needs to store information about the pairing itself (such as Role, Quantity, or Enrollment Date), that confirms a junction object is needed, because a multi-select picklist or a lookup field cannot hold data about the relationship.

Quick Review Summary
- Many-to-many = junction object = custom object with two master-detail fields.
- First master-detail created = primary master = look and feel, owner, division.
- View junction record: Read on both masters. Create/edit/delete: access per Sharing Setting on each master-detail field, usually Read/Write on both.
- No OWD, sharing rules, or manual sharing on a master-detail junction.
- Delete a master: junction records deleted. Undelete: restored. Delete both: gone permanently.
- Roll-up summaries available on both masters.
- Custom report types for cross-master reporting.
- Use two lookups instead when junction records need independent ownership or sharing.

Master these points and you will be able to answer any junction object question on the Advanced Administrator exam by mapping the scenario to the relationship type, then applying the ownership, sharing, deletion, and roll-up rules that follow from the master-detail design.