In one sentence: a record type controls which picklist values are available, which business process applies, and which page layout a user sees. Layout assignment is a grid of profile against record type, so the number of cells you maintain is profiles multiplied by record types. Every record type you add multiplies that grid, which is the real cost and the reason record types are so often the wrong answer.
The assignment grid
Page layout assignment lives at Object Manager, then Record Types, then Page Layout Assignment, or under each profile. One cell per profile per record type, each naming exactly one layout.
Four profiles and three record types is twelve cells. Add a record type and it becomes sixteen. Add a profile and it becomes twenty. Nobody reviews the grid, so cells get filled with whatever layout was default at the time, and users end up on a layout nobody intended. When somebody reports a missing field, this grid is the first place to look, not field-level security.
Picklist values per record type
Each picklist has a master list of values on the field. A record type selects a subset of that list, and a default value for the field within that record type.
Consequences worth knowing:
- Adding a value to the field does not add it to any record type. It has to be added to each record type that needs it, and this is the most common “I added the value but nobody can see it” cause.
- A record can hold a value that its record type does not offer. Changing a record’s record type does not clear values that are no longer available, and reports will show them.
- The Master record type offers all values, which is why records created by integrations that do not set a record type behave differently from records created in the UI.
Business processes
Lead, Opportunity, Case and Solution have business processes, which control the values in Status, Stage, Status and Status respectively. A record type on those objects points at a business process, and the business process is where the stage list is edited. You cannot create an Opportunity record type without first creating a sales process, and forgetting this is why the record type creation screen sometimes offers nothing to select.
The prior question, whether you need a record type at all, is in what a record type actually controls. This section assumes you have decided you do.
When record types are the wrong tool
To hide fields from a group of users. Layouts hide fields from the page, not from reports, list views, the API or exports. If the requirement is access, the answer is field-level security on a permission set.
To vary the layout only. Dynamic Forms gives you conditional field and section visibility on one Lightning page, keyed on any field value or permission, without a record type at all. This is now the better answer for most layout variation.
To categorise records for reporting. A picklist does this, is editable in bulk, and does not touch the assignment grid. Record type is a poor category field because changing it changes behaviour.
To give each team its own version of an object. This is how orgs end up with eleven record types and a matrix nobody can read. If the teams share the same data and the same lifecycle, they can share a record type.
The honest test: if removing the record type would change nothing except which layout appears, use Dynamic Forms instead.
Things that break quietly
Record type names and developer names are different things. Apex, flows and formulas should use the developer name through RecordType.DeveloperName, because the label is translated and editable while the developer name is not.
Deleting a record type requires choosing a replacement for the records that use it, and the reassignment does not adjust picklist values on those records. Expect to clean up afterwards.
Frequently asked
Can two record types share a page layout? Yes, and they often should. Record types exist for picklist values and process as much as for layout.
Does a record type control field-level security? No. Field-level security is set on profiles and permission sets, independently of record type.
Can a flow set a record type? Yes, by setting the RecordTypeId. Look it up by developer name rather than hard-coding the ID.
Why does a user see the wrong layout? Check the profile and record type cell in the assignment grid. The user’s default record type and the record’s actual record type can differ, and the layout follows the record.
