How to roll back unwanted changes in a Salesforce deployment

Written by Nia Owen

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:

1. 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.
2. 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.
3. 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.

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?

This blog post was originally posted on gearset.com. Find out how rollbacks work in Gearset, and how to roll back a deployment with Gearset, in the rest of the blog post here: https://grst.co/3Xc9Lhi