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.
But with Gearset, you can easily roll back any changes with just a few clicks, whether that’s reverting an entire deployment package or removing just a few specific items.
Why do teams need Salesforce rollback?
There are a few reasons why teams might want to roll back changes to a Salesforce org:
- As humans, we’re prone to mistakes. You may release something, then realise it was an error, or perhaps a change was something experimental that was never supposed to make it to production.
- You may release a feature to production, and then find it doesn’t work. Unless you can figure out a hotfix, the best option is probably to roll back, work out what went wrong, then try again.
- You may release changes to production, then find out they’re not quite what the end user wanted. If end users have been involved in the development process, however, this shouldn’t happen too much.
Another reason to roll back could also come from an automated monitoring job flagging some changes to the metadata in production. Gearset’s monitoring tool will flag any unexpected changes that appear in production. Being alerted to these changes and then having the option to roll back will save you a lot of time and a fair few headaches.
Dear Irving on Hudson
Gearset After Hours at NYC Agentforce
What tools are available for Salesforce rollback?
Having a tool that makes this “undo” process seamless means that you can roll back faster. We all know mistakes happen, but for something as important as Salesforce, we should take special precautions as admins and developers to make sure that those mistakes can be dealt with quickly, confidently and simply.
Many an admin or developer has wondered how to roll back a change set in Salesforce. But neither of the native deployment tools on Salesforce — change sets and DevOps Center — offer any rollback functionality. Rollbacks for change sets have been suggested as an idea to Salesforce for over 10 years, but they have yet to implement any kind of rollback functionality.
Change sets also don’t allow you to make destructive changes, so you can’t even run a follow-up change set to remove your changes that way.
Other third-party apps can do a rollback of sorts, if you take a manual snapshot first. But Gearset automatically keeps a snapshot of the target org before each and every deployment, so you can always roll back seamlessly.
Better yet, we offer partial rollbacks: so if you spot a small thing you want to revert, you can roll back that one change without having to undo everything.
Rollback vs backup?
Rollbacks and backups both help you recover your org to an earlier state. But you need both, because they’re designed for different purposes.
Above all, the difference is that backups protect your data as well as metadata, whereas deployment rollbacks are just about metadata. Rollbacks are a great tool to have in your back pocket when a deployment goes wrong, but they won’t save you in a data loss situation.
Backups should also be run automatically on a regular cadence, while rollback snapshots are only taken when you deploy. That means if you haven’t deployed recently, you don’t have a recent snapshot of your org’s metadata.
Ultimately, backups are designed to make sure you can recover anything — no matter what caused the issue and how serious it is. In contrast, rollbacks are about quickly reverting some or all of the changes you’ve deployed. Imagine someone makes a change directly in your production environment that causes a bunch of data to vanish — a rollback can’t help you.
Gearset’s Salesforce backup solution takes a daily snapshot of your org’s data (or on demand) to act as a safety net when something goes wrong. This higher frequency of snapshots means your orgs are always covered — not just when running a deployment. You can then restore your data from the backups and have your orgs back up and running, quickly and securely.
Create a rollback strategy
Creating a rollback strategy can help the whole team and wider business understand the process of rolling back a deployment. Once a rollback has been decided, teams should be taking these steps:
1. Identify the deployment that needs rolling back
Find the deployment in your deployment history that released changes which you need to revert.
2.Communicate with 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 need to alert end users.
3. Decide how much of the deployment 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.
4. 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.
5. Decide the next steps
You should check the rollback has been a success and that no further steps are needed to fix the issue in production. If the original feature is still needed in some form, you’ll want to plan how you’ll identify and fix the issues, then redeploy to production.
Each company and team is different so these steps can be tweaked to fit your whole deployment process.
How do rollbacks work in Gearset?
Thanks to Gearset’s unique comparison engine, every time you run a deployment, Gearset takes a snapshot of your target org which is automatically saved.
That means if you ever need to roll back changes, including CPQ changes, Gearset will run a new comparison between the stored snapshot and the org’s current state. This will highlight what changes have been made since the snapshot, and let you selectively roll back any of the changes. Rollbacks take advantage of Gearset’s unique problem analyzers to make sure the rollback deployment succeeds.
There’s no limit to how far back in your Gearset deployment history you can go to perform a rollback, although it’s worth noting that if you try to roll back a deployment from some time ago, you may see a large number of detected changes between the snapshot and the org’s live state.
And if you’re using source control, you can roll back in the same way — whether you’re deploying to or from an org or code repository.
We’ve already discussed how crucial a reliable rollback strategy is. But what does that actually look like? It’s not just about being able to roll back; it’s also about how easily you can do it. Clear visibility into changes is key. Our customer Fluence, a global energy storage leader, saw this firsthand. They 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.”
What about metadata dependencies?
Missing dependencies can make or break metadata deployments and rolling back changes in Salesforce isn’t simply a case of reversing what you deployed. Creating and then removing changes can impact a wider set of objects than just the items in your original deployment package as a result of dependencies. This means that simply “undoing” the deployment won’t always work, and this is where other approaches to rollback falter.
Gearset’s deep understanding of the metadata in your orgs means it can resolve these complications. When you perform a rollback with Gearset, new object dependencies created by the original deployment are automatically identified, making the rollback process faster and more reliable. You can easily select the changes you want to revert, including any dependencies, and quickly complete the roll back.
How to roll back a deployment with Gearset
With Gearset, rolling back a deployment is simple. You can sign up to a free trial of Gearset to see the UI for yourself and have a go at following these steps:
Identify the deployment that needs rolling back
First, find the deployment you want to roll back from your deployment history, and click Roll back.
Choose the changes to roll back
Gearset will then compare 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, you can then choose exactly which changes to roll back. In this example, we’re removing a couple of Apex classes that were deployed earlier.
Deploy your changes
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 validate the rollback changes first by clicking Validate deployment.
Your rollback is stored in your deployment history
After successfully rolling back your changes, your rollback deployment will be stored in your deployment history, tagged as a rollback. Like any other deployment in your history, you can view the usual deployment report, download the deployment package, and even roll back the rollback if you wish!
Seamless rollbacks
Hopefully you’re on a roll with deployments at the moment, but sooner or later you’ll need rollback. New users can try out rollback for free, along with all other parts of the app, by starting a 30-day trial of Gearset. Or you can book a demo of Gearset today.
If you’re on our starter tier for deployments and would like to upgrade to get access to rollbacks, get in touch to find out how upgrading will help your team protect your orgs!
