Record Types vs Page Layouts in Salesforce
They sound interchangeable, but they do two completely different jobs — and understanding how they hand off to each other is what the confusion is really about.
Record types and page layouts do different jobs. A page layout controls which fields, buttons, and related lists appear on a record. A record type categorizes records — and, combined with a user’s profile, determines which page layout that user actually sees. In short: record types select, page layouts display. They’re built to work together, not as alternatives.
What Record Types and Page Layouts Each Control
The “vs” framing is slightly misleading, because record types and page layouts aren’t competing for the same job. The confusion comes from the fact that you configure them near each other and they both shape what a user sees on a record. But each owns a distinct slice of the experience.
A record type is a categorization tool. On the same object, it lets you offer different business processes, picklist values, and page layouts to different users. A page layout is the canvas: it arranges fields into sections and defines the buttons, actions, and related lists on the record.
Record Type
- Groups records into categories on one object (e.g. “Consulting” vs “Product” opportunities)
- Filters which picklist values are available for that category
- Drives business processes — sales, support, and lead processes tied to the
StageorStatuspath - Decides which page layout a given profile is assigned
- Controls which record types a profile can create
Page Layout
- Places fields into sections and columns on the record
- Sets fields as visible, read-only, or required on that layout
- Defines the buttons and quick actions on the record
- Configures the related lists shown on the record
- Applies to a group of users per object, per record type
How Record Types and Page Layouts Work Together
Here’s the mechanic that ties them together. The page layout a user sees is decided by a combination of the user’s profile and the record type. Salesforce resolves that pairing every time a user views or edits a record.
Without record types, a profile is assigned exactly one page layout per object. That single assignment runs against the built-in --Master-- record type, which every object has by default. The moment you add custom record types, the assignment becomes a grid: for each object, every profile × record type cell maps to one page layout. That’s how one profile can see a lean layout for a “Prospect” account and a detailed layout for a “Client” account — same object, same user, different record type.
You configure this under Setup → Object Manager → [Object] → Page Layout Assignment → Edit Assignment, where Salesforce’s assignment matrix shows a page-layout selector for every profile and record type. This is the same mechanic covered in depth in the full guide to record types in Salesforce, which walks through creating record types, sales processes, and picklist value assignment end to end.
A user can view a record of any record type, even one that isn’t associated with their profile. Associating a record type with a profile controls what that user can create — not what they can read. Assignment governs creation and the layout shown; it isn’t a record-access control.
Page layouts are available in all editions, but record types require Professional, Enterprise, Performance, Unlimited, or Developer Edition. Assigning multiple layouts per profile through record types requires Enterprise, Performance, Unlimited, or Developer Edition.
Record Types vs Page Layouts: Common Points of Confusion
Most of the trouble admins run into comes from expecting one tool to do the other’s job — or from mistaking layout behavior for security.
Neither record types nor page layouts are security features. Setting a field to read-only or hiding it on a page layout is not field-level security — a user can still reach that field through reports, the API, list views, or another layout. Actual field access is governed by field-level security on profiles and permission sets. Record types don’t restrict data access either; they categorize and route.
A few other distinctions worth locking in: “required on the page layout” only enforces the field during edits through that layout — it is not the same as a universally required field defined at the field level or by a validation rule. And picklist value filtering belongs to the record type, not the page layout: if the wrong picklist values are appearing, the record type is the place to look, not the layout.
Keep layout sprawl down. Before cloning a fifth layout to hide two fields, ask whether a record type is genuinely warranted or whether visibility rules would serve better. And always confirm every profile × record type cell has a layout assigned — an unassigned pairing falls back to a default, which is a common cause of “why is this user seeing the wrong fields?”
Where Dynamic Forms Fits Into the Picture
The relationship has shifted in recent releases. With Dynamic Forms, individual field placement and conditional visibility moved out of the page layout and into the Lightning App Builder, where you drag fields onto the record page and show or hide them based on record data, profile, or device.
That doesn’t retire page layouts, and it doesn’t change the record-type story. Migrating a record page to Dynamic Forms does not delete the underlying page layout — the layout still governs related lists, actions (until you adopt Dynamic Actions), mobile experiences, and other places that continue to rely on it. Crucially, the profile × record type → page layout assignment still applies. Record types remain the way you route a category of records to the right experience; Dynamic Forms just gives you finer control over the fields within it. Our guide to page layouts, Lightning pages, and Dynamic Forms covers how those pieces coexist on the modern record page.
Key Exam Facts
- Assignment formula — the page layout shown is decided by
Profile+Record Type. With no custom record types, assignment runs against the--Master--record type. - Not security — record types and page layouts never control data access. Field-level security on profiles and permission sets does.
- Division of labor — record types own picklist values and business processes; page layouts own field arrangement, buttons, and related lists.
- Case Close — on the Case object, the same record type can use a different page layout for closed cases than for open ones.
Test what you know
Practice scenario questions on record types, page layouts, and record page design.
Verified against the official Salesforce Summer ’26 Help & Training documentation on page layout and record type assignment. Study smarter at CertifySF.com.