51 posts tagged with "Deployment"

You move a custom report type from your sandbox to production, and the deploy fails:

INVALID_CROSS_REFERENCE_KEY: In field: baseObject — no CustomObject named MTDT_RT_Obj__c found

The report type is fine where you built it. In the target, the object it's built on isn't there, and the whole thing stops — nothing lands. The fix is to deploy the report type together with its base object and the custom fields it reports on; mtdt.io reads those dependencies and recommends the missing ones before you deploy, so the reference resolves instead of hard-failing.

You deploy a Lightning record page that's worked for months, and the target org rejects it:

The 'component_xxx' component instance doesn't have an identifier specified.

Same FlexiPage, same components. It saves fine in the source org's Lightning App Builder — but the moment you push the retrieved XML to another org, the deploy fails. The cause is the API version the page was retrieved at: component identifiers became required from API v53.0 (Winter '22) on, so a FlexiPage pulled at an older version simply comes down without them, and a newer org rejects it on arrival.

You change a Flow, deploy it, and Salesforce stops you:

This flow is already active and can't be overwritten. Deactivate it first or save as a new version.

Or the deploy goes green — and the flow still isn't running.

You deploy a picklist field that's worked for months, and the target org rejects it:

Global value set 'Account_Tier' cannot be resolved

The field is fine in your source org. The values are right there. But the moment you push it to another org, the deploy fails on a value set it can't find. That's because a Global Value Set is its own separate metadata component — the field only references it by name, and it doesn't ride along with the field automatically. The fix is to deploy the field together with its GlobalValueSet, which is what mtdt.io does by recommending the value set as a dependency whenever it's missing in the target.

You deploy a Lightning web component that's run fine in your sandbox for weeks, and the target org rejects the bundle. The component itself didn't change. In the target, something it leans on — an Apex method, a field, a child component — isn't there, and the deploy fails on it. That's because a bundle is a thin shell that imports things like Apex controllers, fields, child components, static resources, labels, and message channels, and Salesforce resolves every one of those references against the target at deploy time. The fix is to deploy the bundle together with everything it depends on, which is what mtdt.io's Impact Analysis flags for you before the deploy runs.

You edit a search layout — the columns shown in search results, lookup dialogs, and filters — and then try to move it to another org. Salesforce makes it oddly hard: there's no standalone "Search Layout" to deploy, and if you push just the layout, the Metadata API rejects it. That's because a search layout lives inside the object's metadata rather than as its own component, so Salesforce normally forces you to redeploy the whole object just to move one layout change. mtdt.io fixes this by decomposing the object into separate, selectable items, so the search layout deploys on its own without touching the rest of the object.

You push an Apex change to production and the deployment stops:

Average test coverage across all Apex Classes and Triggers is 71%, at least 75% test coverage is required to complete this deployment.

It passed in the sandbox. In production, the org-wide coverage gate — and the rule that one failing test fails the whole deploy — blocks the release. mtdt.io avoids this by recommending exactly which unit tests cover your change, so you deploy with Run Specified Tests — a targeted run — instead of RunAllTests against the whole org.

You migrated your CPQ configuration to the new org. The product rules don't fire. The price rules point at nothing. Half the product options seem to have vanished — and nothing errored. The records are just sitting there, quietly not working.

Because Salesforce CPQ configuration isn't metadata. It's data — and data carries Salesforce IDs that are different in every org.

You add a record type to a deployment, ship it, and Salesforce stops you cold:

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

or the one everyone ends up searching for:

Picklist value: Archived in picklist: RT_Status__c not found

The record type deployed fine in your source org. In the target, it can't find a picklist field — or a value — it relies on.

You update a Schedulable Apex class, deploy it to an org where it's running, and Salesforce stops you:

This schedulable class has jobs pending or in progress.

The class is locked while it has a scheduled job. And even once you get past that, the schedule doesn't come with it — Salesforce deploys the class, not the running job.