name: record-type-id-management description: "RecordType ID differences across orgs: dynamic lookup via Schema.SObjectType methods, DeveloperName for stable refs, hard-coded ID anti-patterns, record-type caching, deployment impact. NOT for record-type strategy or when to use record types (use admin-foundation or data-model-design)." category: admin salesforce-version: "Spring '25+" well-architected-pillars:

• Reliability
• Scalability tags:
• record-type
• developername
• schema-describe
• hardcoded-ids
• deployment triggers:
• "why does my record type id differ between sandbox and production"
• "how do i look up a record type id dynamically in apex or flow"
• "record type developer name vs id best practice"
• "record type id hardcoded in apex causing deployment failure"
• "schema describe record type infos by developername"
• "record type id changes when packaging or deploying" inputs:
• Code or config referencing record types (Apex, Flow, LWC, Validation Rules, Formulas)
• Target environments (sandbox set, packaging org, production)
• Number of record types per object in scope
• Deployment model (metadata API, managed package, unlocked package) outputs:
• Resolution pattern per reference point (Apex / Flow / formula)
• Cleanup plan for hard-coded record-type IDs
• Caching strategy for hot paths
• Deployment test matrix across envs dependencies: [] version: 1.0.0 author: Pranav Nagrecha updated: 2026-04-21

Record Type ID Management

Activate when code, flow, or configuration references record types by ID. Record type IDs are org-specific and change across sandbox refreshes, packaging, and org clones. Hard-coded IDs are one of the most common causes of "works in sandbox, fails in production" deployment failures on Salesforce.

Before Starting

• Grep the codebase for IDs that look like record-type keys. Apex string literals starting with 012 are the smoking gun.
• Prefer DeveloperName over Name. Admins rename labels; DeveloperName is the stable API handle.
• Know the caching story. Schema.SObjectType.RecordTypeInfosByDeveloperName is cached per transaction — safe to call often, but not free across transactions.

Core Concepts

DeveloperName is the stable handle

Record types have three identifiers: Id (org-specific), Name (user-facing label), DeveloperName (API name). Only DeveloperName is stable across orgs. All code and config should reference by DeveloperName, resolving to Id at runtime.

Schema.SObjectType resolution

Apex: Schema.SObjectType.Account.getRecordTypeInfosByDeveloperName().get('Business_Account').getRecordTypeId(). Returns the Id in the current org. Works everywhere — triggers, batch, LWC @AuraEnabled methods.

Flow

Flow formula or Get Records on RecordType with SobjectType and DeveloperName filters. Avoid referencing record-type Ids directly in flow; use the record type lookup component or DeveloperName-based query.

Validation rules and formulas

Formulas can reference $RecordType.DeveloperName (scoped to the context record). Compare to strings rather than IDs. RecordType.DeveloperName = 'Business_Account' survives deployment; RecordTypeId = "012..." does not.

LWC

LWC receives record-type Id via @wire(getObjectInfo) which returns recordTypeInfos keyed by Id with name and developerName attributes. Resolve DeveloperName → Id on the client once per session.

Common Patterns

Pattern: Central Apex utility for record-type resolution

public class RecordTypes {
    public static Id idFor(SObjectType type, String developerName) {
        return type.getDescribe().getRecordTypeInfosByDeveloperName()
                   .get(developerName).getRecordTypeId();
    }
}

Use as RecordTypes.idFor(Account.SObjectType, 'Business_Account'). Cached by the platform; cheap to call repeatedly.

Pattern: Custom Metadata Type as record-type registry

RecordTypeRef__mdt with Object__c, DeveloperName__c, and any semantic flags. Apex/Flow read the CMDT, then resolve to Id. Useful when the same logical "primary" record type differs across products.

Pattern: Validation rule via DeveloperName

AND($RecordType.DeveloperName = 'Business_Account', ISBLANK(Industry)). No ID in the formula. Deploys cleanly to every org.

Decision Guidance

Recommended Workflow

1. Grep codebase for 012[A-Za-z0-9]{12,15} literals and audit every match.
2. Catalog every record type per object with SELECT DeveloperName, SObjectType FROM RecordType.
3. Replace each hard-coded Id with the DeveloperName resolution pattern matching its reference point.
4. Introduce a central RecordTypes utility and migrate Apex references.
5. Update validation rules and formulas to $RecordType.DeveloperName.
6. Run a sandbox-refresh smoke test: deploy to a freshly refreshed sandbox and verify no test failures reference ID literals.
7. Add a CI check that blocks commits containing 18-char record-type IDs.

Review Checklist

• No hard-coded record-type IDs remain in Apex, LWC, Flow, or metadata
• Central Apex utility used for ID resolution
• Validation rules and formulas use $RecordType.DeveloperName
• LWC resolves via getObjectInfo
• Smoke test on freshly refreshed sandbox passes
• CI check blocks new hard-coded record-type IDs
• Documentation notes DeveloperName convention for admins

Salesforce-Specific Gotchas

1. Master record type has DeveloperName Master — handle gracefully when looking up the master programmatically.
2. Inactive record types are not excluded by getRecordTypeInfosByDeveloperName. Filter on isActive() if you care.
3. Change Sets preserve DeveloperName but not Id. The destination org creates a new Id — code that hard-codes Id from the source fails on first run.

Output Artifacts

Related Skills

• apex/apex-mocking-and-stubs — mocking Schema.describe in tests
• data/data-model-design-patterns — record-type strategy itself
• devops/cicd-pipeline-design — CI regex hooks