51 posts tagged with "Deployment"

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.

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.

Most Salesforce deployment failures aren't mysterious. A flow references a field that isn't in the package. A profile change quietly removes access. There's no way to undo it if it goes wrong. These are predictable problems — and yet they usually surface the worst way: after you click Deploy, as a red error or a wave of "I can't see X" tickets.

What if you saw them before? That's what mtdt.io's pre-deployment checks do — run a set of analyzers against your target deployment and flag anything risky while you can still fix it cheaply.

Salesforce DevOps Center was a genuine leap forward. It dragged teams off change sets, put Git at the center of releases, and made source-driven development approachable for admins and devs alike — for free. If you're using it today, you made a good call.

But there's a pattern almost every growing team runs into: somewhere around the 6–12 month mark, DevOps Center starts to feel less like a platform and more like a ceiling. DevOps Center is a starting point, and outgrowing it is the normal arc for a maturing team.

A deployment succeeds, everyone moves on — and an hour later a key flow is misfiring in production. Now what? With native Salesforce tooling, the honest answer is: you rebuild the previous state by hand, under pressure, while production misbehaves.

There's a better answer. Here's why Salesforce rollback is genuinely tricky, and how to turn it into a single click. mtdt.io does it by capturing a rollback point — a snapshot of the target org's metadata — right before a deployment runs; if the release goes wrong, you open the deployment and click Rollback to restore that pre-deployment state.

A few years ago, "Salesforce DevOps" mostly meant "please stop using change sets." In 2026 it means a connected stack of version control, safe deployment, backup & recovery, quality, data, and governance — practices and tools that take a change from a developer's sandbox to production safely, repeatably, and with a way back if something breaks.

If you're assembling (or upgrading) that setup, this is the map: what each layer is for, and how they fit together.

"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.

Here's a workflow most Salesforce teams know too well: make a change, deploy it, then remember to retrieve the metadata and commit it to Git so the repo stays current. That last step is the one that slips — and every time it does, your repo and your org drift a little further apart.

It doesn't have to be a separate, forgettable chore. Your deployment can land in Git automatically.