Creating a record type is a five-minute click in Setup. Rolling it out correctly takes a sprint because each new type drags page layouts, picklist value mappings, business processes, profile assignments, and validation rule changes behind it. Build the whole rollout package in sandbox before promoting any single piece to production.
- Confirm the variant truly needs a record type
Ask whether the difference is enough fields and picklist values to justify the maintenance overhead. If the answer is "we just need to hide two fields" or "we just need different help text," a permission set with FLS may be a better tool. Record types are heavyweight; use them when the form materially differs across user groups.
- Create the supporting business process if needed
For Opportunity, Lead, Case, and Solution, create a new business process first. Object Manager > Sales Processes (or Lead/Support/Solution Process). Pick which stage or status values apply to this variant, in the order they should appear in the picklist.
- Create the page layout for the new record type
Object Manager > target object > Page Layouts > New. Clone an existing layout and modify fields, sections, and related lists for the new variant. Save with a name that includes the record type, like "Renewal Opportunity Layout" so the layout assignment matrix is readable later.
- Create the record type itself
Object Manager > Record Types > New. Pick the business process if applicable, give it a label and API name, and choose which profiles can use it. Set the default page layout assignment per profile during this step or come back to the assignment matrix afterward.
- Configure picklist value availability
For each picklist on the object, edit the record type to control which values are available and which is the default. This is the single most overlooked step. Missing it means users see the full picklist or, worse, an empty picklist.
- Update validation rules to be record-type-aware
Add RecordType.DeveloperName checks to validation rules that should fire only for some variants. A rule requiring a Close Plan field on Net New Opportunities should not fire on Renewal Opportunities. Test each validation rule on every record type before deploying.
- Test as each affected profile
Log in as a user from each profile that has access to the new record type. Open the New screen, confirm the type picker shows the right options, create a record, verify the page layout and picklist values match expectation. Repeat for each profile because layout assignment is per-profile, not global.
Label appears in the type-picker UI. API name is permanent and referenced by validation rules, Apex, and Flow.
Filters which Stage, Status, or equivalent values apply. Required for those objects, ignored elsewhere.
Per profile, which record types are visible and which page layout is the default. Drives the user-facing experience.
- Page layout assignment is per profile per record type. If users on the same profile see different layouts than expected, the assignment matrix is the place to check first, not the layout itself.
- Picklist value filtering must be configured for every picklist on the object after a new record type is added. New picklists added later default to showing all values regardless of record type.
- Validation rules without a RecordType.DeveloperName check fire on every record type. Roll out new record types alongside validation rule updates or expect false-positive errors on records that should pass.
- Changing a record's record type after creation can hide fields, change available picklist values, and trigger different validation rules. Plan as a migration with backfill scripts, not as a routine field edit.
- Default record type per profile streamlines the user experience. Skipping this leaves users on a type-picker screen they consider extra friction, especially for power users creating dozens of records a day.