Record Type Strategy At Scale

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 as a Layout Multiplier Reducer

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 ID Portability

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.

Common Patterns

Pattern 1: Consolidate Record Types, Differentiate with Dynamic Forms

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:

1. Audit existing record types and catalog the actual differences (fields shown, picklist values, business process).
2. Identify record types that share the same business process and picklist values but differ only in field layout.
3. Merge those record types into one, retaining the picklist and business process definition.
4. Build a Dynamic Forms page in Lightning App Builder with component visibility rules to show or hide fields based on a controlling field or the remaining record type.
5. Update the profile layout assignment matrix to remove the retired record types.
6. Migrate existing records using Bulk API to update RecordTypeId to the consolidated record type.

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.

Pattern 2: Business Process Alignment

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:

1. Export RecordType metadata XML for the object. Each record type references a BusinessProcess and contains picklistValues overrides.
2. Map each record type to its actual business meaning (e.g., "Enterprise Sale" vs. "SMB Sale" on Opportunity).
3. Normalize picklist values so that each record type's overrides reflect the real business process, not historical accidents.
4. Remove record types that represent the same business process under different names.
5. Redeploy the cleaned metadata using Metadata API or a change set.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner working on this task:

1. Inventory current state. Query or export record types per object, count profiles, and calculate the current layout assignment count (N x M). Identify the objects with the highest assignment counts as priority targets.
2. Classify each record type by its differentiation axis. For each record type, document whether it exists for field visibility, picklist filtering, business process separation, or a combination. This determines which can be consolidated.
3. Check Dynamic Forms compatibility. Confirm the target objects support Dynamic Forms in Lightning App Builder. If they do not, plan a layout-reduction strategy using fewer, broader layouts instead.
4. Design the target state. Define the minimum set of record types needed for distinct business processes and picklist value sets. Map field-visibility-only differences to Dynamic Forms visibility rules.
5. Plan the data migration. For records on retired record types, prepare a Bulk API update to move RecordTypeId to the consolidated record type. Test in a sandbox first and validate that automation (flows, triggers, validation rules) still fires correctly after the record type change.
6. Deploy metadata changes. Deploy updated RecordType XML, updated ProfileLayout assignments, and any updated flows or validation rules that referenced retired record types. Use Metadata API or change sets.
7. Validate in production. After deployment, verify layout assignments render correctly for each profile, picklist values filter as expected, and reports or dashboards that filter by record type still return correct data.

Review Checklist

Run through these before marking work in this area complete:

• No Apex code or Flow references hardcode Record Type IDs — all use DeveloperName-based resolution
• Layout assignment count (N x M) has been calculated and is within operational tolerance
• Dynamic Forms compatibility has been verified for target objects before planning a migration
• Picklist value overrides per record type align with actual business process requirements
• Data migration plan exists for records on retired record types, including rollback steps
• Profile layout assignment matrix has been updated to remove retired record type rows
• Reports and list views that filter by record type have been reviewed for impact

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

1. Master record type is always available — The "Master" record type cannot be deleted and is always present. If a user's profile has no other record type assigned, they default to Master, which shows all picklist values with no filtering. This silently breaks picklist governance when profiles are misconfigured.
2. Record type assignment is profile-based, not permission-set-based — Permission sets cannot assign record types. Record type availability is controlled exclusively through profiles. This means even permission-set-first orgs must manage record type access through profile assignments.
3. Deleting a record type does not delete the records — When you delete a record type, existing records are reassigned to the default record type for their owner's profile. This can silently change business process membership and picklist value visibility on thousands of records with no audit trail beyond the record type field history (if enabled).

Output Artifacts

Related Skills

• record-types-and-page-layouts — Covers basic record type setup and page layout assignment; use when the org is small or the question is introductory rather than about scale