Edit Before Deployment. The Salesforce deployment feature you didn’t know you needed

July 17, 2025 · 5 min read

Sr. Salesforce Consultant

If you’ve ever deployed something to production in Salesforce and thought, “Oh no, I should’ve changed that one thing…” – this is for you. With mtdt, you can edit your components right before deploying, no need to go back to the sandbox or repackage everything. It’s like having a final review button with actual power.

Why does it matter? Sometimes your changes work perfectly in sandbox, but when you try to deploy… boom – different orgs, missing components, licenses don’t match, etc.

That’s where Edit Before Deployment saves the day. You can tweak stuff last minute and make sure everything fits just right.

Without this feature, your only options are:

Go back and rebuild your deployment package
Or push through and fix it manually in production (which is risky)

With mtdt, you get a smarter option: open the deployment package, make quick edits on the spot, and send only what’s needed – nothing more, nothing less.

Let’s look at how this can save your deployment (and your day) in real-world scenarios:

Cleaning up Lightning Pages for independent orgs

What usually happens:

Your sandbox has Lightning pages with custom buttons or components that don’t exist in the target org (a managed package button, for example). Deployment fails…

How mtdt helps:

You can remove or adjust those components right before deploying. You don’t need to go back into your builder or metadata source. Just open the XML, remove what’s unsupported, and deploy a clean version. Simple.

Partial class deployment (split logic)

What usually happens:

You’ve added new logic to a class, but only part of it is ready to go live. Maybe some logic is still under review or pending testing. You want to push just the “safe” changes.

How mtdt helps:

You can manually trim out the unapproved section of code before deployment, directly in mtdt. Deploy only the updated logic for inserts, and leave the rest in your sandbox for later. It gives you the flexibility to move forward without waiting.

❝
Alex, Salesforce developer, shares his real story:
I had this class where we added new logic for handling account inserts and updates. The insert logic was fully tested and good to go, but the update part still needed some review. Normally, I’d have to either delay the whole deployment or start breaking the class into separate files, which is messy and time-consuming.
With mtdt, I just opened the deployment package, snipped out the unapproved update logic, and deployed only the insert part. No repackaging. No back-and-forth with version control. Just a clean, focused deployment of what was ready. Total lifesaver.

Temporarily disabling a trigger

What usually happens:

Something’s wrong in production. A trigger is misfiring, but there’s no built-in flag or setting to turn it off. You’re stuck.

How mtdt helps:

You can open the trigger code, comment it out, or wrap it in a conditional, all right before deployment. This allows you to react fast and get production stable, without changing your whole development plan.

Adjusting environment-specific settings

What usually happens:

You’ve got remote site settings, custom metadata, or CSP trusted sites with different values in sandbox vs. production, like different endpoint URLs or API tokens.

How mtdt helps:

Instead of logging into production and changing these manually (which is error-prone and hard to track), you can adjust them right in the deployment package. That way, everything is part of the same controlled deployment — clean, documented, and easy to audit.

❝
Nick, DevOps engineer, talks about his experience:
We had different remote site URLs between sandbox and production – pretty typical, right? But if you forget to update them before deployment, you end up with broken integrations or security issues. I used to handle this manually after the deployment, but that always felt risky and kind of hacky.
Now, with mtdt, I just open the XML before I deploy. I update the production values right there; it’s quick, clean, and versioned. No last-minute production edits, no mistakes. It’s all part of the same deployment process, just how it should be.

Changing the profile license

What usually happens:

You’ve updated user profiles in your sandbox, added new permissions — everything looks great. But in production, the users are on a different Salesforce license. The deployment fails or applies the wrong license.

How mtdt helps:

Just before you deploy, open the profile file, change the license type, and you’re good to go. No need to rebuild the profile or start from scratch. It takes 30 seconds and saves hours of troubleshooting.

Rolling back changes in production

What Usually Happens:

A deployment was sent to production by mistake (it happens!), or the client asked to reverse a recent update. Now you need to roll it back, but without affecting everything else in your environments.

How mtdt helps:

You can prepare a quick rollback — maybe restore a previous version of a component or undo a metadata change — and push it only to production. It’s fast, targeted, and doesn’t mess with your sandbox or staging setup.