Salesforce Basics: 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 genuinely 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. 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.

You assign layouts in Object Manager under Page Layouts using the Page Layout Assignment button. The grid displays 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.

🧭 360 Card — Record Types & Page Layouts

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: Page layouts alone first. Reach for Dynamic Forms when the only difference is which fields show. Reach for a Record Type when the object genuinely runs different PROCESSES (different picklist values, sales, or support paths). 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 (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, or different downstream automation indicate the business genuinely runs two processes on one object.
• They are over-engineering when the only difference is which fields appear on screen.
• Dynamic Forms visibility rules or component filters on the page handle visibility without multiplying layouts, profile-to-layout matrices, and automation branches.
• Design Smell: If every automation opens with if RecordType = X and the number of X values keeps growing, the object is likely two separate objects in disguise.

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.

• The Classic Break: A user gets object access through a permission set, but nobody assigned record types there.
• They land on the org default or master type, leading to "wrong layout, missing picklist values" tickets.
• In permission-set-led orgs, record-type assignment must move into permission sets as well. Leaving it solely on profiles is what breaks provisioning.

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 as long as the divisions share the core concept of a Case (same status meanings, SLA structures, and reporting needs). The payoff is unified reporting and shared automation.

• Split into separate objects only when variants stop being cases (different lifecycles, retention policies, or security models).
• A split costs unified service reporting and doubles the integration surface.
• The Decision Test: Does the third division fit the existing process with a new record type and a stage subset? If yes, use a record type; if states do not map, split the object.

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

A: Use a Record Type when the data shape is identical and only picklists, layouts, or processes differ. Use a New Object when fields, relationships, or volumes differ — a different data shape requires a separate table. Quick test: If half the fields remain blank for one type, you needed a new object. (e.g., Express vs. Standard delivery = Record Types on Delivery__c; Delivery vs. Vehicle Service Job = two distinct objects).

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

A: No. Record type visibility controls which types a user may select and which one defaults — that is UI configuration, not access control. Sharing decides which rows a user sees, while CRUD and FLS decide object and field access. A user who cannot select a record type can still view and edit records of that type if sharing permits it. Using record types to attempt to hide data is a common mistake.

Recommended Reading: Big Objects & Data Archival