64 posts tagged with "Salesforce"

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.

Ask where your Salesforce backup actually lives, and the answer is usually "somewhere in the vendor's cloud, in a format you'll see only if you ever need a restore." That's fine — right up until you want to query it, report on it, prove what changed, or simply own your own data.

mtdt.io's smart data backup takes a different stance: your Salesforce records are backed up into your own PostgreSQL database — a real, queryable database you control, with a full history of every backup, ready to restore back into an org.

The fastest way to break production is to let everyone deploy to it. As a team grows, "anyone can push anything, anytime" stops being agility and starts being risk. What you want instead is separation of duties: people propose changes, and a smaller set of trusted reviewers sign them off.

mtdt.io's deployment approvals build that directly into the deploy flow — role-based, enforced at the moment of deploy, with extra protection for your most important orgs.