Record Types & Page Layout Strategy 💬 In plain words: Record Types let one object act like different forms for different teams. Different picklist values, page layouts, and processes — same Account object. Use them for truly different business processes. Not for cosmetic layout changes. 📌 Example: One Account object, two businesses: 'Retail Customer' record type shows B2C picklist values and layout. 'Enterprise Client' shows contract fields and a different sales process. Same table, two costumes. 🧠One object, many costumes: A Record Type is a costume on the same object — different picklists and layouts, same table underneath. Concept Record Types split one object into business variants. • Each type can carry its own subset of picklist values, its own business process — Lead, Case and Opportunity stages — and its own page layout per profile. • Lightning has changed the calculus. Dynamic Forms and conditional comp...
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 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 you create is the
primary one.
• The junction takes its look and feel, its
ownership and its sharing from that parent.
• Deleting either master deletes the junction
rows, though undelete behaves differently depending on which side went first.
• A junction is also where the data about the relationship itself lives: dates, roles, status on the association.
🧠360 Card —
Junction Objects & Schema Limits
Nobody picks
the primary master by ticking a box. It is decided by the order you create the
fields: the first master-detail you add wins. That is why you cannot see it
easily in Setup — you check it with Workbench or the Metadata API. To swap it,
you convert both relationships down to lookup and then back to master-detail in
the order you want. So decide the order before you build, not after.
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 it rolls up to both sides.
Price: the junction inherits sharing from both
parents. A user needs access to both, so access gets harder to reason about,
not easier.
Limits: exactly two Master-Details, so a third leg must
be a Lookup. The first relationship you create is primary: it drives look and
feel and detail sharing. Delete both masters and undeleting one will not bring
the junction rows back.
Mirror — two lookups
instead: independent sharing and
no cascade, but you lose roll-ups on both legs and you own the cleanup.
Later: this is what makes the "keep the slots
free" rule in 2.1 matter. Spend a Master-Detail on convenience and the
junction is no longer possible.
At volume: a junction sits under two parents, so it is
twice as exposed to parent-lock contention.
⚠ INTERVIEW TRAP: The primary master-detail is decided by
CREATION ORDER, not by a setting. Create them in the wrong order and you must
convert both to lookup 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 masters.
• A user needs at least read access on both
parents to see the junction record. And you configure the required access level
on each Master-Detail relationship.
• The first relationship you create is the primary
one. It controls owner inheritance and the detail-page association.
• Common mistake: creating them in the wrong
order.
• The only fix is to delete and recreate the
relationship, and on a populated object that means data surgery. So pick the
primary side deliberately — usually the parent that matters more to the
business.
Follow-ups (scenario-based)
Q1: What happens to junction
records if one master record is deleted and then undeleted?
A1: Delete
a master and the junction rows cascade-delete with it.
• Undelete that master and they come back. But
if BOTH masters were deleted, undeleting one does not bring the junction
records back.
• Once the second master goes, they are gone
for good.
• That asymmetry matters in data-retention
conversations, and this is a classic 'have you actually run this' probe.
Q2: You are hitting the
2-Master-Detail-per-object ceiling on a schema with three-way associations. How
do you model it?
A2: You
have three options. Make the third relationship a required Lookup on the
junction.
• You lose cascade delete and roll-ups on that
leg, but the association is still queryable.
• Or split into two junctions, chained through
a middle object.
• Or step back and ask whether that third
'relationship' is really an attribute — a picklist or a reference field —
rather than a full participant.
• The architect answer adds the reporting
consequence.
• Standard report types traverse only so much
relationship depth.
Read this:- Custom Metadata Types vs Custom Settings vs Custom Labels