Record Type
A record type is a Salesforce configuration that lets a single object (Account, Opportunity, Case, or any custom object) behave like multiple variants, each with its own page layout, picklist values, and business process.
Definition
A record type is a Salesforce configuration that lets a single object (Account, Opportunity, Case, or any custom object) behave like multiple variants, each with its own page layout, picklist values, and business process. The same Account object can serve as a B2B customer, a partner, or a personal-account household by switching record types, and the user sees a different form and stage flow for each variant without the data living in separate tables.
Record types are the layer that connects three pieces of customization: which fields show up on the page (page layout assignment), which picklist values are available (picklist value filtering), and what stage or status sequence applies (business process selection). Profiles and permission sets control which record types each user can see and create. A single object can host dozens of record types, but most production orgs settle on three to five per object before the maintenance cost overtakes the flexibility benefit.
How record types shape the user experience for one object
Page layout assignment per record type and profile
Each record type can map to a different page layout for each profile. A Sales user opening a Direct-Sale Opportunity sees a streamlined layout focused on close date and amount. A Renewals user opening a Renewal Opportunity sees a different layout with renewal date, churn risk, and product family fields. The Layout Assignment matrix lives at Object Manager > Record Types > Page Layout Assignment, and the wrong assignment is the most common reason a user reports "I cannot see the fields I need."
Picklist value filtering
Record types control which picklist values are available in each variant. A Type__c picklist on Account might have values like Customer, Partner, Prospect, and Competitor. The B2B record type exposes Customer and Partner. The Personal Account record type exposes Customer only. Filtering happens at the field level, so each picklist needs its values mapped to each record type. Salesforce calls this "Picklists Available for Editing" and it is the second-most-common source of "missing values" support tickets.
Business processes drive stage and status flows
For Opportunity, Lead, Case, and Solution, record types tie to a Sales Process, Lead Process, Support Process, or Solution Process. These are filtered picklists on the Stage, Status, or equivalent state field that control which sequence of values each variant follows. A Renewal Opportunity might skip Qualification and start at Negotiation. A Net New Opportunity walks through all stages. Each business process is configured once and assigned to any number of record types.
Default record type per profile
Each user profile can set a default record type per object. When a user clicks New on Account, the form opens with the profile default unless they explicitly pick another. If a profile has access to only one record type, the platform skips the type-picker screen entirely. This UX detail matters: users on profiles with multiple types see an extra step that some interpret as friction. Reduce the type list per profile to only what the role actually creates.
Conversion, reassignment, and reporting
Changing a record's type after creation is possible but cascades. The new record type may expose different fields, hide values, or require different stages. Validation rules tied to the old type may fire on the next save, and reports filtered by record type suddenly count the record differently. Lightning Web Components and Apex code that branches on record type need to keep up. Plan record type changes as a migration, not a routine edit.
Record types versus separate objects
Some teams confuse "we need different forms" with "we need separate objects." Record types are the right answer when the data shape is mostly the same and only some fields and picklists differ. Separate objects are the right answer when ownership, sharing, security, or fundamental schema differs. The line between the two is fuzzy, but as a rule of thumb: if a report needs to count all variants together, record types win. If a report should never mix the variants, separate objects might be cleaner.
Common pitfalls in record type rollouts
Three failures recur across orgs. First, profile-to-layout assignment matrix is left at defaults, so users see the wrong fields and complain on day one. Second, picklist value filtering is forgotten for new picklists added after the record type rollout, leaving values invisible until someone notices. Third, record types are created in sandbox but never deployed properly with their layout and process assignments, producing a partial config in production. Treat record type changes as a deployment package with all three pieces.
How to create and roll out a Record Type
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.
Trust & references
Cross-checked against the following references.
- Record Types OverviewSalesforce Help
- Create Record TypesSalesforce Help
- Create a Sales ProcessSalesforce Help
Straight from the source - Salesforce's reference material on Record Type.
- Create Record TypesSalesforce Help
- Record Type ConsiderationsSalesforce Help
- Best Practices for Record TypesSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. In which area of Salesforce would you typically find Record Type?
Q2. Can a Salesforce admin configure Record Type without writing code?
Q3. What is the primary benefit of Record Type for Salesforce administrators?
Discussion
Loading discussion…