Use when designing or refactoring record types across objects with many profiles, business processes, or picklist variations. Covers layout assignment explosion, Dynamic Forms migration, and record type ID portability. NOT for basic record type setup or page layout assignment — see record-types-and-page-layouts for introductory guidance.
This skill activates when a practitioner is dealing with record type proliferation across objects that have accumulated many profiles, business processes, or picklist overrides. It provides patterns for rationalizing record types, managing the quadratic layout assignment problem, and migrating toward Dynamic Forms where supported.
Gather this context before working on anything in this domain:
Every record type on an object must have a page layout assigned for every profile in the org. If an object has 8 record types and the org has 50 profiles, that is 400 layout assignment cells to manage. Adding one record type adds 50 new assignments; adding one profile adds 8. This grows quadratically and is the primary driver of record type sprawl pain. The profile-based layout assignment matrix is stored in the ProfileLayout metadata type and must be deployed per profile.
Dynamic Forms, available in Lightning App Builder, allows field-level visibility rules on a single page layout rather than requiring a separate layout per record type. A visibility filter can show or hide fields based on record type, field values, permissions, or device form factor. This means one flexible page can replace several static layouts. However, Dynamic Forms is not available on all standard objects — check compatibility before planning a migration. As of Spring '25, it supports Account, Contact, Opportunity, Case, Lead, and custom objects, but not all standard objects.
Record Type IDs are org-specific 18-character Salesforce IDs. They are not stable across sandboxes and production. Code or configuration that hardcodes a Record Type ID will break on deployment. The canonical Apex pattern for resolving Record Type IDs at runtime is Schema.SObjectType.Account.getRecordTypeInfosByDeveloperName().get('Enterprise').getRecordTypeId(). In metadata (flows, validation rules), use $Record.RecordType.DeveloperName rather than a literal ID. In formulas, use RecordType.DeveloperName comparisons.
When to use: An object has 5+ record types where the differences are primarily field visibility rather than distinct business processes or picklist value sets.
How it works:
Why not the alternative: Keeping separate record types solely for field visibility means every new profile multiplies the layout assignment burden. Dynamic Forms eliminates that multiplier for field-visibility-only differences.
When to use: Record types have drifted from their original business process intent and picklist values are inconsistent across record types on the same object.
How it works:
| Situation | Recommended Approach | Reason |
|---|---|---|
| Field visibility is the only difference between record types | Consolidate record types and use Dynamic Forms | Eliminates N x M layout explosion for field-only differences |
| Record types drive distinct picklist value sets or business processes | Keep separate record types | Picklist filtering and business process (Sales Process, Support Process) require distinct record types |
| Record Type IDs are referenced in Apex or Flows | Replace with DeveloperName-based lookups | IDs are org-specific and break across environments |
| Object is not Dynamic Forms compatible | Use fewer record types with broader layouts | Cannot rely on Dynamic Forms; minimize layout assignments manually |
| Org has 50+ profiles and growing | Migrate to permission sets and reduce profile count | Fewer profiles directly reduces the M in the N x M equation |
Step-by-step instructions for an AI agent or practitioner working on this task:
Run through these before marking work in this area complete:
Non-obvious platform behaviors that cause real production problems:
| Artifact | Description |
|---|---|
| Record type rationalization plan | Document listing each object's current and target record type count, consolidation mapping, and Dynamic Forms eligibility |
| Layout assignment matrix | Before and after grid of record types by profiles showing assignment reductions |
| Migration checklist | Step-by-step checklist for data migration, metadata deployment, and post-deployment validation |