Alina Hubaidullina

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.

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.

You spent the afternoon building in a sandbox — a couple of fields on Account, a tweak to a flow, a new permission set, an Apex class. Now you need to move it to the next org. Quick question: what exactly did you change?

Salesforce won't tell you on its own — but a source-tracked org (a scratch org, or a sandbox with source tracking enabled) already records every metadata change you make. mtdt.io's Source Tracking reads that log: start a Record Session, build normally, and it lists every component you touched by name — ready to retrieve, download, deploy, or open as a pull request, no CLI required. Without it, you rebuild the list from memory, click through Setup hunting for every component, and hope you didn't miss the one field that quietly breaks everything downstream.

Most Salesforce metadata is text — XML you can read, diff, and merge. Static resources aren't. They're files: a logo, a JavaScript library, a CSS bundle, a zipped folder of assets. And the moment a deployment has to carry a binary, the usual text-and-files workflows start to creak.

You deploy the metadata, the release goes green — and then someone opens the Developer Console on the target org to run "that one script": re-schedule the nightly job, set a custom-setting value, kick off a backfill. It's a manual step, it's easy to forget, and forgetting it means the deploy looked successful but the org isn't actually finished.

mtdt.io closes that gap: it can run a block of anonymous Apex on the target org automatically, the moment a deployment succeeds.

"Just deploy the one thing I changed" sounds simple. On Salesforce, it's one of the easiest ways to quietly break production.

The problem isn't deploying less — it's that Salesforce treats what you leave out as a decision. Here's why partial deployments are risky, when you actually need them, and how to do field-level deploys without the landmines.

Profiles in Salesforce are powerful... and frustrating. They define what users can see and do, but managing them across environments has long been a complex task for admins and developers. If you’ve ever tried to change the license type of a profile, migrate a community profile to internal users, or even just clone an existing profile with slight modifications, you’ve likely hit a wall of Salesforce limitations.

The new Profile Cloner in mtdt.io is built to change that.