A record type earns its place when the same object needs different picklist values, a different page layout, or a different business process for different groups of records. That is the whole list. Everything else people reach for record types to do has a cheaper answer, and the bill for a record type is not the ten minutes it takes to create one — it’s the page layout assignment grid you maintain for the rest of the org’s life.
What a record type actually controls
Four things. Being precise matters here, because most of the misuse comes from believing there’s a fifth.
Picklist value subsets. Each record type gets its own selected values from the master picklist. This is the strongest reason to use record types and the only one with no real substitute — a Case with an Issue Type of “Billing dispute” for one business unit and “Warranty claim” for another, from one field.
Page layout assignment. With record types in play, the page layout a user sees is determined by their profile combined with the record’s record type.
Business process. Sales processes on Opportunity, support processes on Case, lead processes on Lead — each is a record-type-scoped subset of the stage or status picklist, and each drives its own Path.
Which types a user can create. Assigned on the profile or a permission set, plus a default.
The fifth thing it does not control is read access. Salesforce’s own guidance is direct about this: don’t use record types as an access control mechanism. Profile assignment governs create and edit access for an object but not read access. A user with no assignment to the Partner Opportunity record type cannot create one, and can open, report on, and export every Partner Opportunity that sharing gives them. If someone in your org has implemented data segregation with record types, it is not doing what they think.
The multiplication problem
Do the arithmetic before you create the second one. Page layout assignment is a matrix of record types by profiles, per object. Six record types and twelve profiles is 72 cells, and every cell can independently point at the wrong layout without producing an error anywhere. Nobody reviews 72 cells. What happens instead is that a support ticket arrives, someone fixes one cell, and the other 71 keep drifting.
Picklist assignment multiplies too, and it’s worse because it’s silent. Adding a value to the master picklist does not add it to any record type — you go into each record type and include it. Miss one and users on that record type simply never see the new value. There’s no warning, no report that flags it, and the person who reports the bug three months later describes it as “the picklist is missing an option.”
Then every new field has to be added to every layout it belongs on, and every layout has to be checked when a field is removed. Six record types with distinct layouts means a field change is a six-layout change. That is the real cost, and it compounds with each record type, not with each object.
What people use record types for, and what to use instead
| What you actually need | Record type? | Cheaper option |
|---|---|---|
| Different picklist values for different segments | Yes | Dependent picklist, if the controlling value is already on the record |
| A different stage or status sequence | Yes | None — business processes are record-type-scoped |
| Different fields visible to different teams | No | Dynamic Forms component visibility, or field-level security |
| Different fields depending on a value on the record | No | Dynamic Forms visibility rules keyed on that field |
| Different validation for different segments | No | One validation rule with a formula on a plain picklist |
| Something to group reports and list views by | No | A plain picklist field |
| Restricting who can see which records | No | Sharing model — OWD, roles, sharing rules |
| A genuinely different data model with few shared fields | No | A separate object |
Two rows are worth arguing about. Dynamic Forms handles “different fields for different people or different data” without touching record types, which removes most of the historical reason for creating them. At the cost of conditional logic spread across dozens of component-level rules instead of one legible grid. And the separate object is right more often than people admit: if two record types share eight fields out of sixty, you have two objects wearing one name, and every report and automation on it filters by record type forever.
Removing a record type is much harder than adding one
This asymmetry is what makes sprawl permanent, so understand the exit before you take the entrance. Deactivating a record type does not remove it from any profile or permission set. It means no new records can be created with it. Existing records keep the record type and keep displaying its assigned layout. Deactivation isn’t cleanup. It’s freezing.
To get a record type genuinely out of an object you remove it from every profile and permission set first, then deactivate it. And you can’t end up with zero: the documented approach for clearing all record types from an object is to remove them all from profiles, deactivate them, then create and activate one new record type that you assign to nobody, because one record type has to exist for records created under the deactivated ones to display properly. Business and person accounts require at least one active record type outright.
Deleting a record type also deletes the Path associated with it. And if you have criteria-based sharing rules keyed on record type (on Account, Case, Contact, Opportunity, or a custom object) changing record types changes what those rules share, silently, at the next recalculation.
Then there’s the data migration nobody scopes properly. Mass-updating records from record type A to record type B changes their layout, their available picklist values, and possibly their sharing in one operation. The values already stored in a picklist field stay stored even if they aren’t valid for the new record type: the records look fine until a user opens one, changes something unrelated, and the save fails on a value they never chose. Audit picklist value assignments across both record types before you move a single record.
Finally, record type Ids are org-specific. Any formula, flow, validation rule, or Apex class with a hard-coded 012... Id works in the sandbox it was written in and nowhere else. Look them up by developer name:
Id b2b = Schema.SObjectType.Opportunity
.getRecordTypeInfosByDeveloperName()
.get('B2B_Direct')
.getRecordTypeId();Once you have decided to use them, the profile and layout assignment grid is its own piece of work, covered in record types and page layout assignment.
The test before you add one
Three questions, and a no to all three means you don’t need one. Do these records need different picklist values from the same field? A different stage or status sequence? Is the layout difference something Dynamic Forms visibility can’t express?
Then a question about your org rather than the requirement: how many layouts and profiles does this new record type multiply against? If that number is one you wouldn’t review by hand, find another solution.
Frequently asked
How many record types is too many?
The number that matters isn’t record types, it’s record types multiplied by page layouts and profiles. My rule of thumb: past four record types on one object, someone should be able to explain on request why each exists and what breaks if it’s merged. If nobody can, you have sprawl regardless of the count. Check your actual ceiling at Setup → Object Manager → [Object] → Object Limits.
Can I delete a record type that has records assigned to it?
You’ll be asked to reassign those records to another record type as part of deleting it, and that reassignment brings the picklist-validity problem described above. Deactivating instead leaves the records where they are and just stops new ones.
Do record types control field-level security?
No. Field-level security comes from profiles and permission sets and is entirely independent of record type. A field hidden on one record type’s page layout is still readable through reports, list views, and the API by anyone with FLS read on it.
Does changing a record’s record type fire automation?
Yes: RecordTypeId is a field, so a change to it is an update, and triggers, flows, and validation rules all run. Mass record type changes are mass DML, with all the bulk behaviour and governor limits that implies.
Should I use record types or Dynamic Forms?
Dynamic Forms if the requirement is purely which fields appear. Record types if the requirement touches picklist values or the stage sequence. In practice a lot of orgs want both: record types for the data rules, one Lightning page with visibility rules instead of six layouts.
Reference: Considerations for Creating and Updating Record Types and Picklists, Limitations for Creating and Updating Record Types and Picklists, Assign Record Types and Page Layouts in Profiles, and Tailor Business Processes to Different Record Types Users, Salesforce Help.
