Skip to main content

Deploying Record Types

A record type is rarely self-contained. For every picklist on its object it stores which values are available under that record type — so it only deploys cleanly when those picklist fields already exist in the target, with the values it references. Deploy a record type on its own and Salesforce stops with:

Global value set 'Tier__c' in record type 'Partner' on the entity 'Account' cannot be resolved

or its value-level cousin:

Picklist value: Archived in picklist: RT_Status__c not found

The first means the field is missing in the target; the second means the field exists but is missing a value the record type assigns. The fix for both is the same: deploy the record type together with the picklist fields it depends on.

mtdt.io bundles the dependencies for you​

Add the record type to a deployment and expand it — mtdt.io shows what it depends on:

Record type expanded — Depends on lists the picklist fields it needs, with New / Different status

Run Analyze → Impact analysis (or just start a deploy) and those fields come back as recommendations, each tagged with how it was found and its status against the target:

Impact analysis recommending the record type's picklist fields to include

Here Tier__c is New (missing in the target) and RT_Status__c is Different (it exists, but the target lacks the Archived value the record type uses). Tick them to add them to the deployment, and the record type and its fields ship as one consistent unit — the field carries its full value set, the record type's assignments resolve, and "cannot be resolved" never happens.

Why "Different" matters​

A record type change often rides on a value-only difference — a picklist value the target doesn't have yet. Tools that compare by last modified date can call those two fields identical. mtdt.io compares the actual metadata, so RT_Status__c shows up as Different purely because Archived is missing — and that value travels with the field when you deploy the bundle.

Notes​

  • A restricted-picklist change raises the deployment's risk, so mtdt.io offers a rollback checkpoint and recommends backing up the affected object's records first.
  • Salesforce can't delete a record type through the Metadata API — deploys create and update them, but removing one is a manual step in the target org.

For the checks that run before every deploy, see Pre-deployment checks. For the why and the full story, see deploying Salesforce record types.