How to rollback a Salesforce change using Git without having to use the command line.
In this article, we'll explore the practical solutions to rolling back unwanted changes and bugs in Salesforce using Git, without needing advanced Git knowledge. From understanding how Git works as a source control tool, to the detailed processes offered by Blue Canvas for various rollback scenarios, this piece aims to empower you with a reliable strategy for Salesforce disaster recovery and system confidence.
Here are our 5 Key Takeaways:
Have you ever been working on a change set, clicked submit and then thought to yourself “uh oh?” Or perhaps you’ve just finished a release and your inbox is blowing up with complaints from your end users about a broken field? Or maybe your VP of IT is calling you at 2 in the morning because she got a call from her CEO?
In all of these cases, you are probably wishing that Salesforce made it easy to “undo” a deployment. Well, unfortunately, Salesforce doesn’t make it easy.
However, there is a way to rollback unwanted changes and bugs in Salesforce using Git that doesn’t require you to be a GIt wiz.
Git is a source control tool that contains snapshots of previous states of your codebase. Blue Canvas automatically snaps “commits” for all changes as they are made. As soon as a user clicks “save” in the Salesforce UI or any change happens in the system, Blue Canvas creates a small back up of that change.
Uniquely, Blue Canvas does this for Apex code but also declarative metadata like Workflow Rules, Process Builder, Custom Fields and even Reports, Dashboards and Email Templates.
This automatic snapshotting tool creates automatic Git commits for all changes in your system without having to change your process at all. Users don’t have to go to the command line and diligently commit their changes. You don’t have to run a Jenkins process with an Ant script to commit things for you. All changes end up in Git automatically.
You can then use the Blue Canvas interface to selectively return to previous states of the application based on this commit history.
Because Blue Canvas is based on Git, there are multiple ways to rollback changes to your Salesforce orgs. We provide a number of options. You can:
Each org has a series of snapshots of its metadata stored in a standard Git repository. This makes rolling back to previous states as easy as selecting a timestamp in a dropdown menu and clicking “rollback”.
But you can also restore an org from from a previous version of another org. Let’s say that you had a sandbox that you wanted to populate with the contents of your production org, 2 weeks ago. You can do that with Git and with Blue Canvas.
And most importantly of all, these are not broad snapshots. These are highly granular commits that occur on each component and in real time. So you can do partial rollbacks. If you’ve been working on a release for several weeks and one small component or feature isn’t working in production, you can just rollback that one feature without rolling back everything.
Furthermore, because we use the Salesforce DX directory format, you can actually rollback specific changes to custom fields rather than entire objects. This makes it possible to do a partial rollback of an object or a field rather than a total “undo.”
It’s also worth noting that with Blue Canvas you can rollback changes that were not specifically deployed through Blue Canvas. This is crucial. If an admin goes into production and starts making changes outside of your established process, you can still roll that back because we automatically commit changes into Git on save.
Salesforce is mission critical part of the revenue engine for most organizations. Salesforce downtime can cost millions in lost revenue and productivity. (Given the importance of Salesforce and it’s highly customizable nature, it’s almost shocking that Salesforce doesn’t offer any kind of rollback or back up functionality out of the box.)
Salesforce is also a tool that powers businesses and lets them achieve their loftiest goals. So it has to be a dynamic system that can be changed without fear. If you’re not pushing the boundaries and innovating you’re going to lose to the competition.
Rollbacks solve this tension for teams. You can push the envelope from a feature development perspective while protecting and securing your mission critical CRM infrastructure.
Rollbacks allow you to deploy with confidence. You can deploy new code and configuration changes secure in the knowledge that you can always rollback changes as needed.
Now your business applications can improve and evolve at the pace of your business. Blue Canvas’ rollback technology is even more powerful because it’s a very precise scalpel. This ability to rollback partially permits your team to be even more aggressive with improving business processes.
Just as you wouldn’t buy a house without insurance, it’s a good idea to have a disaster recovery plan in place if you’re going to spend hundreds of thousands or millions of dollars annually on Salesforce licenses, support, apps, salaries and professional services.
Rollbacks provide the ability to restore your orgs and sandboxes in case something goes wrong. It’s a simple and effective disaster recovery plan.
We’ve worked with Salesforce teams who have lost significant work (i.e. months of code on a team of 20 in some cases) through a sandbox refresh or introduced bugs that hit sales productivity for several days. Just imagine what would happen if that happened at the end of a quarter.
Our white paper on the ROI of salesforce release management lays it out well. An ill-timed Sandbox refresh or a rogue change in production can cost tens of thousands of dollars per hour. If that happens even once a year you could be losing thousands unnecessarily.
Protecting your org with a Salesforce backup and rollback tool as well as some release management process is definitely a good way to go. Whether you are using Blue Canvas to do so or not, Git provides the best foundation for doing so and we could not recommend that you set it up more.
.png)