Click Deploy Rollback: How to Undo a Salesforce Deployment

TL;DR: A Salesforce click deploy has no native undo button. The Metadata API rolls back a deployment that fails, but once one succeeds, going back means redeploying the previous version, deleting what was added and restoring any data by hand. Take a snapshot before you click, or use a tool that takes one for you.

What is a click deploy in Salesforce?

A click deploy moves metadata between orgs through a UI: you compare a source and a target, tick the changed components, validate and deploy, with no change set and no command line. The term comes from ClickDeploy, which Copado now sells as Copado Essentials; we cover the tool and its pricing in how ClickDeploy works and what it costs. Most guides stop at the deploy. This one covers what happens when you need to take it back.

What happens when a click deploy fails?

In production, nothing changes. Salesforce only accepts all-or-none deployments there (the rollbackOnError option must be true), so the Metadata API rolls the whole transaction back on error and the org stays as it was. The Salesforce CLI rolls back by default and lets you override that with --ignore-errors, but its own reference says never to use it against production, because components with errors are skipped and the org can end up inconsistent. If a deploy fails, fix the cause and rerun it; our guide to click deploy errors walks through the usual culprits.

Can you undo a successful click deploy?

Not natively. As Gearset puts it, change sets cannot reverse a deployment and neither can DevOps Center, and change sets cannot make destructive changes either. A successful deploy is simply the new state of the org. To go back, you run a second deployment that restores the old state, and that only works if you kept a copy of it.

That makes the backup, not the rollback, the step that matters. If nobody captured the target components before the click, you are rebuilding them from memory.

How do you roll back a click deploy, step by step?

1. Decide: roll back or fix forward. If the cause is obvious and the fix is small, shipping the fix keeps the rest of the release. Roll back when diagnosis will take too long or the change is actively causing harm.
2. Find the pre-deploy version. Use the snapshot your tool took, or the last commit in Git that matches production. Without either, retrieve what you can from a sandbox that has not been refreshed since.
3. Build the rollback package. Components the deploy modified go back in at their previous version. Components the deploy added go into a destructiveChangesPost.xml manifest so they are deleted after the restore succeeds.
4. Validate first. Run it as a check-only deployment (--dry-run in the CLI) with the same Apex test level you would use for any production release.
5. Deploy and verify. Deploy, then smoke-test the affected pages, flows and integrations. Record what was reverted and why.
6. Check the data. A metadata rollback does not restore records. Handle data separately, as covered below.

Steps 2 and 3 are where most rollbacks go wrong, which is why the click deploy checklist makes a backup part of the pre-flight, not an afterthought.

Which click deploy tools include rollback?

• Copado Essentials: choose Deploy with backup and a Rollback button appears on the deployment record, per its help center. CI job rollbacks require a Git repository as the source.
• Gearset: saves a snapshot of the target org's metadata before every deployment and supports full or partial rollback, according to its documentation.
• AutoRABIT: rollback works only if Take Backup was enabled on the original deployment, its knowledge base notes, and lets you exclude components.

For Salto, Flosum, Blue Canvas and any other tool on your shortlist, ask the same two questions: is the backup automatic or opt-in, and can you roll back one component without reverting the whole release?

What can a rollback not undo?

• Data. Deployment rollbacks are metadata only. Records changed by a new flow or trigger stay changed.
• Deleted fields, cleanly. Salesforce keeps a deleted custom field for 15 days, but Salesforce Ben lists what undelete leaves for you to redo, such as required and unique settings and field history tracking.
• A purge. Deleting with --purge-on-delete skips the Recycle Bin, so there is nothing to restore.

The more reliable fix is a history you can replay. Deploying from a branch means every release was committed before it shipped, as shown in click deploy from Git.

How does Tekunda handle rollback?

Tekunda is the Salesforce consulting and product company behind Serpent, the DevOps platform it also runs on its own client delivery. Serpent keeps the click-to-select workflow while Git and pull requests run underneath, so every release has a version to return to. Rollback is one click, for a single component or a full release. Teams on Copado can follow our migration path, plans are on the pricing page, and more guides live in the SF Guides library.

FAQ

Does Salesforce have a rollback button for deployments?

No. Change sets and DevOps Center cannot reverse a deployment. You redeploy the previous version or use a tool that snapshots the org first.

Does a failed click deploy change anything?

Not in production, where Salesforce requires all-or-none deployments. The Salesforce CLI also rolls back on error unless you pass --ignore-errors.

Can I roll back data with a deployment rollback?

No. Rollbacks restore metadata only, so records need a separate data backup and restore.

How long can I restore a deleted custom field?

For 15 days, unless it was erased or purged. Some attributes must then be restored by hand.