Record Types & Page Layout Strategy

 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 component visibility cut down how many layouts you actually need. So modern designs use fewer record types and lean on dynamic rendering.

•  Record types also set default values, and they are commonly used as the branching key in automation.

🧭 360 Card — Record Types & Page Layouts 

You assign layouts in Object Manager, under Page Layouts, using the Page Layout Assignment button. The grid there has one row per profile and one column per record type. So you can see every gap at once. An empty cell is the bug people hunt for weeks.

Rule:  Record Type when the same object runs genuinely different processes. Never for cosmetics.

Gain:  one table. Shared reporting, shared automation. Different picklists, paths and layouts per business.

Reach for:  the page layout alone first. Reach for Dynamic Forms when the only difference is which fields show, because that needs no new record type. Reach for a Record Type when the object genuinely runs different PROCESSES. Different picklist values, different sales or support path. Reach for a separate object only when the two things share almost no fields and no reporting.

Price:  every record type multiplies layout assignments and picklist maintenance. Two types across three profiles is six assignments to keep straight.

Limits:  layout assignment is by profile plus record type. A user with no record type assigned falls back to the Master layout, which is the classic provisioning break. Permission sets can grant record types too.

Mirror — a separate object:  clean separation and its own volume. The cost is duplicated automation and split reporting.

Later:  this shapes reports, flow entry conditions and permission sets for years.

At volume:  record types cost nothing in query performance. Layout sprawl costs admin time, and that is the real bill.

⚠ INTERVIEW TRAP:  Record types are NOT a security feature. Record type visibility controls what a user can SELECT, not what they can see. Sharing decides which rows.

Core Q&A

Q: When is a Record Type the right tool, and when is it over-engineering?

🎯 Say this first:  Record Type when the same object runs genuinely different business processes (different picklists, paths, layouts); over-engineering when it's only cosmetic.

A: Record Types are the right tool when the variants differ in PROCESS.

•  Different stage paths. Different picklist universes.

•  Different downstream automation. In other words, the business genuinely runs two processes on one object. They are over-engineering when the only difference is which fields appear.

•  Dynamic Forms visibility rules, or component filters on the page, handle that without multiplying layouts, profile-to-layout matrices and automation branches.

•  Here is a smell worth naming.

•  If every automation opens with 'if RecordType = X'. And the number of X keeps growing, the object is probably two objects.

Follow-ups (scenario-based)

Q1: What is the interaction between Record Types and profiles/permission sets, and what commonly breaks at user provisioning?

A1: Profiles and permission sets control which record types a user can SELECT, and which one is their default.

•  Layout assignment is done by profile plus record type.

•  Here is the classic break. A user gets object access through a permission set, but nobody assigned record types there.

•  So they land on the org default or the master type, and the 'wrong layout, missing picklist values' tickets start.

•  In an org that leads with permission sets — see 1.2 — record-type assignment must move into permission sets too.

•  Leaving it on profiles is what breaks.

Q2: Two divisions share the Case object with different processes today, and a third division is onboarding next quarter. Record types or separate objects?

A2: Stay on one object with record types while the divisions still share the idea of a case. Same status meanings. Same Service Level Agreement (SLA). Same reporting world. The payoff is shared reporting and shared automation.

•  Split into separate objects only when the variants stop being cases at all.

•  Different lifecycle, different retention, different security model — that is a real split.

•  A split costs you unified service reporting. It also doubles the integration surface.

•  For the third division, the test is simple.

•  Does it fit the existing process with a new record type and a stage subset?

•  If yes, use a record type.

•  If its states do not map, that is your evidence to split.

Q (compare): Record Types vs a separate object — when is a new object the right answer?

A: Record Type when the data shape is the same and only picklists, layouts, or process differ.

•  New object when the fields, relationships, or volumes differ — a different shape wants a different table.

•  Quick test: if half the fields sit blank for one type, you wanted a new object.

•  Skyline: Express vs Standard delivery = record types on Delivery__c; Delivery vs Vehicle Service Job = two objects.

Q (compare): Are Record Types a security feature?

A: No, and saying that plainly scores well.

•  Record type visibility controls which types a user may select, and which one defaults. That is user interface and defaulting, not access control.

•  Sharing decides which rows a user sees.

•  CRUD and FLS decide which objects and fields.

•  A user who cannot select a record type can still see and edit records of that type if sharing lets them.

•  Common mistake: using record types to hide data.