How to roll back unwanted changes in a Salesforce deployment

We can all think of times when having an “undo” button has saved our skin. For Salesforce developers, hitting deploy can often feel like the moment of truth. What if something goes wrong? How will I revert my changes if they break something? How will I redeploy the changes?

Trying to roll back a Salesforce org to an earlier state is normally a difficult, slow, and frustrating process where developers and admins manually revert changes one at a time.

This post covers what triggers a rollback, what separates a rollback you can rely on from one you can’t, how rollback differs from backup, and how to reverse a deployment (or part of one) in Gearset.

What does rollback mean in Salesforce?

A rollback reverts your org to the state it was in before a particular deployment ran. Salesforce offers no native way to do it, so teams either redeploy an earlier version from source control or use a platform that snapshots the target org before every deployment.

Why do Salesforce teams need rollback?

Deployments to production are all or nothing. If one component fails, Salesforce applies none of the changes and leaves the org as it was. So the deployment that needs rolling back is the one that succeeded and turned out to be wrong.

Reasons to roll back include:

• Human error. Something reaches production that shouldn’t have, or an experimental change goes further than anyone intended.
• A change that doesn’t work as expected once it’s live.
• A release that works exactly as built, but isn’t what the end user asked for.
• A regression/breaking change. The new change works as intended, but it breaks something else in the org.

Automated change monitoring is another trigger. A monitoring job comparing daily snapshots of production will flag metadata that appeared without going through your release process, and rolling it back is often the quickest way to deal with it.

The State of Salesforce DevOps 2026 report found that 18% of teams primarily find issues in production, in the operate and observe stages of the DevOps lifecycle. For those teams, rollback is part of the release process.

What tools are available for Salesforce rollback?

Neither of Salesforce’s native deployment tools offers a way back. Change sets can’t reverse a deployment, and neither can DevOps Center. Rollback for change sets has been suggested as an idea to Salesforce for well over a decade, and still isn’t implemented.

Change sets also don’t allow you to make destructive changes, so running a follow-up change set to remove what you deployed isn’t an option either.

Third-party rollback offerings vary more than they first appear. Some can roll back, but only if you take a manual snapshot before the deployment runs, which makes the safety net depend on someone setting it up on exactly the day they’re least likely to think of it.

Rollback is one capability among many when you’re assessing tooling. Our guide to Salesforce DevOps tools covers where coverage falls away across the wider lifecycle.

Why rolling back isn’t just reversing the deployment

Rolling back isn’t a case of undoing what you deployed in reverse order. Creating and then removing changes can affect a wider set of objects than the items in your original deployment package, because of the dependencies between them. That’s where approaches built on simply re-running the deployment backwards fall down.

Knowing what a change touches before it ships can help avoid these complications.

What good rollback capability looks like

Not all rollback works the same way, and the differences only show up on the day you need it. These are the questions worth asking about whatever tool you’re using:

• Is the snapshot automatic? A rollback you have to switch on before deploying protects you on the days you remember. A snapshot taken on every deployment protects you on the day you forget.
• Can you revert part of it? Most bad releases contain one bad change and a lot of good ones. All-or-nothing reversal turns a small problem into a large one.
• Does it account for dependencies? The reversal has to handle objects the original deployment created relationships with, not just the components listed in the package.
• Is the rollback itself recorded? A rollback is a release event, and it should leave the same evidence as any other deployment.
• How far back does history reach? A snapshot you can’t get to isn’t a snapshot.

Rollback vs backup?

Rollback and backup both get your org back to an earlier state, but you need both because they cover different ground. Backups protect your data as well as your metadata, while deployment rollbacks are metadata only.

Backups also run automatically on a regular cadence, while rollback snapshots only exist because you deployed. If you haven’t deployed recently, you don’t have a recent snapshot of your org’s metadata.

So backups are built to recover anything, whatever caused the problem and however serious it is. Rollbacks are for quickly reverting some or all of what you just deployed. If someone makes a change directly in production and a batch of data disappears, a rollback won’t help.

Create a rollback strategy

Not every bad release needs rolling back. A rollback strategy helps the whole team and the wider business agree what happens when one does, and who does it. Here are the steps to follow:

1. Decide whether to fix forward or roll back. If the cause is obvious and the fix is small, shipping the fix is usually faster than reversing the release, particularly if you release through an automated pipeline. You keep everything else that went out, and there’s no second deployment to unwind later. Choose to roll back when the cause isn’t clear, when the fix would take longer than the reversal, or when the change is doing active harm while you investigate. Diagnosis time is the deciding factor: if you can’t say what broke within a few minutes, roll back first and diagnose after.

2. Identify the deployment that needs rolling back. Find the deployment in your deployment history that released changes which you need to revert.

3. Tell the rest of the team. The rest of the team and key stakeholders will need to know that the rollback is happening. Decide who will perform the rollback and who will run the comms during and after. Some companies might have an internal team that looks after rollbacks, or the issue might be big enough to warrant alerting end users.

4. Decide how much to roll back. Work out the scope of the rollback. You rarely need to roll back an entire deployment, so a partial rollback might be better.

5. Perform the rollback. Take the relevant steps to roll back and then spot check the org with some testing to make sure everything is running as it should be.

6. Decide the next steps. Check the rollback succeeded and that production is stable. If the change is still wanted, fix it properly and redeploy.

Each company and team is different, so these steps can be tweaked to fit your deployment process.

How do rollbacks work in Gearset?

Every time you run a deployment, Gearset takes a snapshot of the target org and saves it automatically. Rolling back runs a fresh comparison between that snapshot and the org’s current state, shows what’s changed since, and lets you select exactly what to revert — including the dependencies the original deployment created, so reverting a component doesn’t strand the objects that referenced it. Gearset’s problem analyzers run on the rollback the same way they run on any deployment, to help identify issues and improve the likelihood that the reversal succeeds.

Your deployment history has no limit on how far back you can go, though rolling back a deployment from several months ago will surface a large number of changes between the snapshot and the org’s live state.

If you’re using source control, rollback works the same way, whether you’re deploying to or from an org or a repository. The same applies to change monitoring: when a monitoring job flags metadata that appeared in production outside your release process, reverting it starts from the same comparison.

Roll back one change without undoing the release

You rarely need to reverse an entire deployment. Usually one component caused the problem and the rest of the release is fine. With Gearset, because the rollback starts from a comparison rather than a stored package, every changed component is listed individually, and you choose which ones to revert.

Whether you’re reverting one component or the whole release, the process is the same. Here are the four steps.

Find the deployment

Open your deployment history, find the deployment you want to reverse, and click Roll back.

Choose the changes to roll back

Gearset compares the org’s current state with a snapshot of the org taken just before the original deployment you want to roll back. From this comparison, choose exactly which changes to reverse. In this example, we’re removing a couple of Apex classes that were deployed earlier.

Deploy the rollback

After selecting the items to roll back, click Next to be taken to the pre-deployment summary. Then click Deploy now to complete the rollback process, or check it first by clicking Validate deployment.

Your rollback is stored in your deployment history

The rollback is stored in your deployment history, tagged as a rollback, with its own deployment report and downloadable package. A rollback is a release event, and it leaves the same evidence as any other deployment.

A usable rollback depends not only on whether you can perform it but also on whether you can see what you’re reverting. Our customer Fluence, a global energy storage leader, put it this way:

Now with Gearset, the advantage is that I have this comparison in front of me. If there is a scenario where we have to roll back, we can just go back to the previous data. It is super easy. You have it all in front of you.

Rollback you can rely on

No matter how careful you are, issues can arise after a deployment. Recovering quickly means having a rollback you can rely on, one that lets you undo the affected part of a release in minutes rather than the whole thing. See how Gearset can help with a 30-day trial, or book a demo with our expert team.