record-type-strategy-at-scale

# Record Type Strategy At Scale

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.

---

## Before Starting

Gather this context before working on anything in this domain:

- How many record types exist per object and how many profiles exist in the org? The layout assignment count is N record types multiplied by M profiles, so even modest growth creates quadratic complexity.
- Are practitioners assuming that record types are the only way to control field visibility? Dynamic Forms (Lightning App Builder component visibility filters) can replace many record-type-driven layout differences without creating new record types.
- Governor limits on record types per object are generous (200), but the real constraint is the operational cost of maintaining N times M layout assignments and the associated picklist value matrices.

---

## Core Concepts

### The N x M Layout Assignment Problem

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

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

---

## 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

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

---

## 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