Create a record type only when a group of records follows a genuinely different process: other picklist values, other stages or statuses, or a split you must report on. If the difference is only which fields people see, use one Lightning record page with Dynamic Forms and visibility rules. Page layouts still matter for some standard objects and related lists. Field-level security, not layout, decides who can read or edit a field.
What does each tool on a record page actually control?
Record types decide which process and values apply to a record. Layouts, Lightning pages and Dynamic Forms decide what a user sees and where it sits on screen.
- Record types carry three things: a set of allowed picklist values, a business process on objects that have one, and a page layout assignment per profile. Business processes exist for opportunities (sales processes), cases (support processes), leads and solutions.
- Page layouts arrange fields, related lists and buttons in the record detail area. Each profile and record type pairing points to exactly one layout.
- Lightning record pages are built in Lightning App Builder. You can assign them per app, per record type and per profile, and they hold components such as related lists, tabs and the highlights panel.
- Dynamic Forms replaces the single Record Detail block with individual fields and sections, each with its own visibility rule. Dynamic Actions do the same for buttons.
- Compact layouts pick the key fields shown in the highlights panel, hover cards and the mobile record header. They can differ per record type.
- Path draws the stage or status bar with guidance and key fields for each step. You configure a path per record type, so a new record type usually needs a new path too.
When is a new record type actually justified?
Justify one when records need their own picklist values, stage list or reporting split. Visual differences alone do not qualify.
A useful test is to ask what breaks if the two groups share one record type. Suppose renewals would show new-business stages, or warranty cases would offer complaint statuses. Then a record type earns its place. If the answer is that some people would see three extra fields, a visibility rule will do.
- Different lifecycle: separate stage, status or lead process values that must not mix.
- Different picklist choices on the same field, such as product lines that each carry their own reasons or categories.
- Reporting where the type itself is the dimension leaders filter by, and no existing field already captures it.
Things that rarely justify one: a team wanting its own field order, one region needing two extra fields, or a manager preferring a shorter screen. Those are page design questions.
Which tool should you use, side by side?
| Tool | What it controls | Use it when | Watch out for |
|---|---|---|---|
| Record type | Picklist values, business process, layout assignment by profile | Records follow a separate lifecycle or need their own value lists | Every new one multiplies layouts, paths, tests and automation branches |
| Page layout | Fields, sections, related lists and buttons in the detail area | Objects without Dynamic Forms support, or standard-object actions | Copies per profile drift apart; read-only on a layout is not security |
| Lightning record page | Components, tabs and overall page structure | Different apps or teams need a different page around the same data | Too many page variants recreate layout sprawl one level up |
| Dynamic Forms and Dynamic Actions | Individual fields, sections and buttons with visibility rules | Field differences depend on a value, the user or the device | Rules scattered across many fields are hard to audit |
| Compact layout | Header fields, hover cards and mobile record header | Users need different key facts per record type | Often forgotten when a record type is added |
| Path | Stage guidance and key fields per step | A record moves through clear, ordered statuses | One path per record type, so sprawl repeats here |
| Field-level security | Whether a user can read or edit a field anywhere | Data must be hidden or protected from some users | Hiding a field on a page does not apply this |
What does record type sprawl really cost?
Each extra record type adds work in places that are invisible on the record page. The cost shows up in assignments, reporting, automation and every later data change.
- The assignment matrix grows multiplicatively. Five record types across eight profiles means forty layout assignments to keep straight, before Lightning page assignments are counted.
- Picklist values must be enabled per record type. A new value added to the field often silently fails to appear because nobody ticked it on every type.
- Reports split by type need constant upkeep, and leaders lose trust when totals differ depending on which types were filtered.
- Flows, validation rules, formulas and Apex frequently branch on record type. Hard-coded record type IDs differ between sandbox and production, so deployments break; reference the developer name instead.
- Data loads and migrations must map every source row to the right type, and imports fail on values the chosen type does not allow.
Can Dynamic Forms replace extra record types and layouts?
Often, yes, for differences that are purely about which fields appear. Salesforce itself presents Dynamic Forms as a way to cut the number of layouts and record types an org needs.
Visibility rules can test a field value on the record, the user's profile or permissions, and the device form factor. One page can then show export fields only when Country is not the home market, or hide finance details from users without a custom permission. That replaces several cloned layouts with one page and a short list of rules.
Dynamic Forms works on custom objects and on most standard objects that are enabled for Lightning Web Components. Salesforce Help names Tasks, Events and Products as objects that are not, so they keep using page layouts. Check the current Dynamic Forms considerations page for your release before you plan, as coverage keeps widening.
How do you migrate a page layout to Dynamic Forms?
Open the Lightning record page in Lightning App Builder, select the Record Detail component and click Upgrade Now. The wizard copies fields and sections from the page layout you pick onto the page.
- Pick the layout most users already see as the source, not the longest one.
- Delete fields nobody fills in before you write a single visibility rule for them.
- Replace each cloned layout's differences with a rule, then retire the clone once its users are on the new page.
- Build in a sandbox and test as real users from each profile, on desktop and phone.
Is hiding a field on a layout the same as securing it?
No. Layouts and visibility rules only shape the screen, while field-level security controls access everywhere: reports, list views, search, exports and the API.
Salesforce Help is explicit that field-level security should restrict access, while page layouts organize the page. When the two disagree, the more restrictive setting wins. A field left off a layout or hidden by a rule can still appear in a report. An integration can still change it.
Users holding the Edit Read Only Fields permission can also edit fields marked read-only on a layout. So salary, margin or health details belong behind field-level security granted through permission sets. For structuring that access, see our permission set migration guide.
Do visibility rules slow pages down or get hard to maintain?
A handful of clear rules is easier to run than a stack of cloned layouts. Hundreds of field-by-field rules are not, and very large pages load more slowly whichever way they are built.
Keep rules at the section level where you can, so one condition governs a group of related fields. Prefer a rule on one stable field, such as a type or stage value, over long chains of AND and OR conditions. Avoid placing the same field twice with different rules; Salesforce Help warns that this can cause problems at run time.
Record each rule's purpose somewhere people will look. Our guide to documenting a Salesforce org suggests keeping one row per Lightning page, listing its rules and owner.
What changes for mobile users?
Phone users see a shorter record page, and the compact layout drives the header. Check that Dynamic Forms and Dynamic Actions are switched on for mobile in Setup, then test on a real device.
Salesforce added Dynamic Forms on Mobile through the Salesforce Mobile App settings, starting with accounts, cases, contacts, leads, opportunities and custom objects. Help also notes that offline draft edits are not supported once it is on. Visibility rules on form factor let you drop desktop-only sections from the phone view entirely. If your field teams work offline or on a tailored mobile app, confirm the current behavior with your Salesforce account team before relying on it.
How do you consolidate record types without breaking things?
Inventory first, prove usage with data, rebuild the differences as values or rules, then move records and automation together. Retire the old type last.
- Inventory every record type with its picklist settings, business process, layouts, Lightning pages, compact layout and path.
- Run a report of record counts and last-modified dates by type. Types with few recent records are the easiest to merge.
- Search flows, validation rules, formulas, Apex, reports and integrations for each type's developer name and ID.
- Decide what replaces the type: often a picklist field such as Segment, plus visibility rules on the shared page.
- In a sandbox, update automation first, then reassign records with Data Loader or a flow and recheck picklist values on the target type.
- Deactivate the old type, monitor errors and reports for a cycle, and only then delete it.
In one manufacturing org, several inexperienced admins had left a system no rep would use. We merged its record types and stripped out the duplicate fields and automations confusing people. Once Outlook and NetSuite were connected too, the company had all 99 reps using Salesforce inside 30 days.
What naming and governance keep this from sprawling again?
Make new record types a reviewed decision, not an admin's quick fix. A short checklist and an owner per object are usually enough.
- Name record types for the business process, such as New Business or Renewal, not for a team or person.
- Keep developer names stable and reference them in automation, never IDs.
- Require the lifecycle test above, written down, before anyone creates a type.
- Review record types, layouts and pages at least once a year and retire anything without recent records or users.
If page clutter is already hurting usage, our piece on why Salesforce adoption is low covers the people side. A Salesforce optimization engagement can handle the cleanup itself.
