Rollback Strategies for Failed Salesforce Deployments

Short answer: Salesforce has no undo button. A production deployment that fails rolls itself back, because rollbackOnError must be true when you deploy to production, but a deployment that succeeds and turns out to be wrong is yours to reverse by hand. Your realistic options are a reverse deployment from a pre-release snapshot, a targeted destructive change, or a forward fix, and which of them is available to you is decided before you deploy, not after.

Why is there no rollback button in Salesforce?

Salesforce commits metadata straight into the org. There is no transaction log to unwind and no previous version of the org to switch back to. The Metadata API gives you exactly one safety net, and it only covers outright failure: for a production deployment, rollbackOnError must be set to true, so if any component in the package fails, the whole deployment is discarded and the org is left as it was (Salesforce Metadata API developer guide).

That net does nothing for the case teams actually fear. A release that deploys cleanly, passes every test, and then breaks a business process at nine in the morning is not a failed deployment in Salesforce terms. Reversing it means building and shipping a new deployment, and you can only build that one from something you captured earlier.

What can actually be rolled back, and what cannot?

This is the question every rollback plan should start with, and it is where most plans are silent. Sort your release into three buckets before you write a single step.

• Reversible by redeploying the old version. Apex classes and triggers, Lightning web components, flows, layouts, validation rules, permission sets and most declarative configuration. If you have the previous source, you can put it back.
• Recoverable inside a window. A deleted custom field lands in Deleted Fields in Object Manager and can be undeleted with its data for 15 days, after which it is gone. Restoring the field does not restore the page layouts it was removed from (background on restoring deleted fields).
• Effectively irreversible. Deleted picklist values, field type conversions that truncate data, records rewritten by a bad flow or trigger, and roll-up summary fields deleted through the Metadata API, which bypass the Recycle Bin entirely (Salesforce documentation on deleting components).

The third bucket is where rollback plans quietly fail. Metadata rollback restores configuration, never data. If your release ran an automation across 400,000 records, redeploying yesterday's Apex changes nothing about those records.

What are the realistic rollback strategies?

1. Reverse deployment from source control

The most reliable option. If the branch that produced the release is in Git, the previous commit is your rollback artifact. You build a package from the last known-good commit and deploy it over the top. This only covers components the release changed or added, so it needs to be paired with strategy three.

2. Restore from a metadata snapshot

Capture the state of the target org immediately before the deployment, then use that snapshot to generate the reverse package if you need it. This covers the case where the org has drifted from Git, which in most Salesforce teams it has. Tools in this category automate the capture and the diff: Gearset, AutoRABIT and Blue Canvas all document snapshot or restore based rollback, and Serpent ships one-click rollback on every plan, including the free one.

3. Destructive changes for anything you added

A reverse deployment updates components that existed before. It does not remove the ones your release created, so a new object or field stays behind unless you delete it explicitly. That means a destructiveChanges.xml manifest, a separate artifact you have to write. Use destructiveChangesPre.xml to delete before the additions land and destructiveChangesPost.xml to delete after, which is how you unwind dependencies such as an Apex class that still references the object you want gone.

4. Roll forward instead

Often the right call. If the fault is a single validation rule or one line of Apex, a hotfix through the normal pipeline is faster and safer than reversing a package of 200 components. Roll back when the blast radius is unknown. Roll forward when it is small and understood.

How do you roll back a failed Salesforce deployment, step by step?

1. Stop the pipeline so no further release stacks on top of the broken one.
2. Name the blast radius: which components, which automations, which records.
3. Decide rollback or forward fix, and tell stakeholders which one you chose.
4. Build the reverse package from the pre-release snapshot or the last known-good commit.
5. Add a destructive manifest for anything the release created.
6. Validate the reverse package against production before you run it, so you do not turn one incident into two.
7. Deploy, then verify the business process rather than the deployment status.
8. Repair data separately, from backup, and only once the metadata is stable.

What should you decide before you deploy?

A rollback is a design decision made at build time. Answer these five before the release goes out.

• Where is the pre-release snapshot of the target org, and did it actually run?
• Which components in this release fall into the irreversible bucket?
• Does anything need a destructive manifest, and is it written and reviewed?
• Is there a data backup taken close enough to the release to be useful?
• Who decides to roll back, and what is the signal that triggers it?

Validating before you deploy is the cheapest prevention available. A validation with tests stays usable for 10 days and lets you quick deploy the same package without rerunning Apex tests, so there is little excuse for finding compile errors in production. More release playbooks are in our SF Guides library.

FAQ

Does Salesforce roll back a failed deployment automatically?

Yes, but only for deployments that fail. Production deployments require rollbackOnError to be true, so a failing component discards the whole package. A successful deployment is never reversed for you.

Can change sets be rolled back?

Not natively. There is no reverse button, so teams build a second change set that redeploys the previous version, which only works if someone captured that version first.

Does a metadata rollback restore my data?

No. Metadata and data are separate problems. Reversing configuration does not undo records that an automation created, updated or deleted, so you need a backup and a restore plan for that.

How long do I have to recover a deleted custom field?

15 days. The field sits in Deleted Fields in Object Manager and can be undeleted with its data inside that window, though you may have to re-add it to page layouts manually.