44 posts tagged with "DevOps"

You refresh a sandbox, and a day later the tickets start: users can't log in, a workflow blasted a test email to a real customer, an integration is quietly hitting production, and the feature someone spent a week building is gone. All of it is expected — a refresh replaces the sandbox with a fresh copy of its production source, and that one reset touches a lot of things at once.

Here's the complete checklist, grouped and ordered so you handle the dangerous things first.

You give one profile a different set of search-results columns on an object — a profile search layout — and deploy it to another org. On a custom object, Salesforce rejects it:

Profile Search Layout: profile name - Sales User - is not applicable for object

The layout deployed fine where you built it. In the target, the profile isn't "applicable" for that object — and the error doesn't tell you which of the requirements is missing. On a custom object, a profile is only "applicable" when the object has search enabled, has a custom tab, and the profile has read access to the object — miss any one and the deploy fails. mtdt.io fixes this by flagging the missing tab and read access before you deploy, through Impact Analysis and its Profiles & Permissions check.

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.

It's easy to assume Salesforce keeps a copy of everything and will hand it back if something goes wrong. It doesn't. Under Salesforce's shared-responsibility model, the platform keeps the service running; protecting your data and configuration is on you. So sooner or later every team has to plan a backup — and the options vary a lot more than "switch it on."

Here's a neutral checklist of what actually matters, before you commit to any approach.