Salesforce Basics: Junction Objects & Schema Limits

💬 In plain words: A junction object is a small "middle table" with two master-details, used when both sides can have many of each other (Students ↔ Courses → Enrollment). It's how you build many-to-many relationships on the platform.

📌 Example: Students and Courses: one student takes many courses, one course has many students. Create Enrollment with two Master-Details — the junction. Ravi's enrollment in 'Apex 101' is one Enrollment record carrying grade and enrollment date.

🧠 The middle table: Many-to-many = two master-details meeting in a small middle object. Students and Courses meet in Enrollment; Skyline's Parcels and Routes meet in a Stop.

🔗 Connects to: The master-detail choice both legs depend on  ·  One busy parent record creates data skew at scale

Concept

A junction object models many-to-many. It is a custom object with two Master-Detail relationships.

• The first Master-Detail relationship you create is the primary one.
• The junction inherits its look and feel, ownership, and sharing from that primary parent.
• Deleting either master cascade-deletes the junction rows, though undelete behaves differently depending on whether both parents were deleted.
• A junction is also where data about the relationship itself lives: dates, roles, status, or grades on the association.

Nobody picks the primary master by checking a box. It is decided strictly by the order you create the fields: the first Master-Detail relationship you add wins. That is why you cannot see it easily in Setup — you verify it with Workbench or the Metadata API. To swap it, you must convert both relationships down to Lookups and then back to Master-Details in the desired order. Decide the order before you build, not after.

🧭 360 Card — Junction Objects & Schema Limits

Rule: Many-to-many means one small middle object carrying two Master-Details.

Gain: A real row for the relationship. It holds its own fields (grade, date, quantity) and rolls up to both parent sides.

Price: The junction inherits sharing from both parents. A user needs access to both, so access logic becomes additive and complex.

Limits: Exactly two Master-Details per custom object (a third leg must be a Lookup). The first relationship created is primary, driving look-and-feel and detail sharing. If both masters are deleted, undeleting one will not bring the junction rows back.

Mirror — two lookups instead: Independent sharing and no cascade deletion, but you lose roll-up summary capability on both legs and must manage orphan cleanup manually.

Later: This makes managing Master-Detail slot limits critical. Spend a slot unnecessarily elsewhere, and a junction object becomes impossible.

At volume: Because a junction sits under two parents, it is twice as exposed to parent-record locking contention during parallel operations.

⚠ INTERVIEW TRAP: The primary Master-Detail relationship is decided by CREATION ORDER, not by a Setup UI toggle. Create them in the wrong order and you must convert both to lookups and back to fix it.

Core Q&A

Q: How does sharing work on a junction object, and why does the order of creating the two Master-Details matter?

🎯 Say this first: The junction inherits sharing from BOTH masters. A user needs access to both. The FIRST master-detail you create is the primary — it controls look-and-feel and detail sharing.

A: The junction inherits sharing from BOTH parents.

• A user needs at least Read access on both parent records to view the junction record. You configure the required access level on each Master-Detail relationship definition.
• The first relationship created is the primary master. It controls owner inheritance and detail-page association.
• Common Mistake: Creating relationships in the wrong order.
• The only fix is deleting and recreating the relationship, which requires data migration on populated objects. Always choose the primary side deliberately — usually the parent that represents the core business entity.

Follow-ups (Scenario-Based)

Q1: What happens to junction records if one master record is deleted and then undeleted?

A1: Deleting a master record cascade-deletes its junction rows automatically.

• Undeleting that master restores the junction rows. However, if BOTH master records are deleted, undeleting just one parent will NOT restore the junction records.
• Once the second master is deleted, the junction records are permanently purged from the Recycle Bin.
• This asymmetry is critical during data-retention and disaster-recovery architecture reviews.

Q2: You are hitting the 2-Master-Detail-per-object ceiling on a schema with three-way associations. How do you model it?

A2: Evaluate three architectural patterns:

• Option 1: Make the third relationship a required Lookup on the junction. You lose cascade deletion and roll-up capabilities on that third leg, but the association remains queryable.
• Option 2: Split the structure into two separate junction objects chained through an intermediate object.
• Option 3: Re-evaluate whether the third association is actually an attribute (a picklist or reference field) rather than a true relationship parent.
• Reporting Impact: Standard report types traverse limited relationship depth. Deeply normalized models may require Custom Report Types or a flattened reporting object.

Recommended Reading: Custom Metadata Types vs Custom Settings vs Custom Labels