Change Management for Salesforce Admins

by Amber Joseph
Managing changes between Sandbox and Production environments is an important part of maintaining a well organised Salesforce org. Unfortunately, it's not always clear as a Salesforce Admin what the best way to do this is! Should you just manually recreate everything you do in Sandbox in Production?
  
Fortunately, there are easier ways. Here's an overview of 3 different ways to manage changes between orgs in Salesforce for Admins.  

Change Sets

A Change Set in Salesforce is kind of a like basket that we can put all our changes in and then send from one org to another. The important thing to know about Change Sets is that they can only contain modifications you can make through the Setup menu. No record data!
  
Change Sets are easy enough to understand. When you want to send a Change Set from a Sandbox org to a Production org, you create an Outbound Change Set (you can search this up in Setup). When you want to take everything from your Change Set and put it into your current org, you search up Inbound Change Sets in Setup, and then look for the Change Set you just sent (from your Outbound one). Then click deploy.
  
Change Set Salesforce Admin Diagram
   
It's important that you run tests before you deploy a Change Set to make sure nothing is going to break when you do deploy it, but often it's not as easy as you may think. Change Sets have some major drawbacks. There is no ability to:
  
  • Resolve Merge Conflicts between orgs
  • Move changes from multiple Sandboxes into one org
  • Trace changes back to tickets or requirements
  • Back up changes
  • Schedule syncs between orgs
  • Roll-back changes
To use Change Sets you have to keep a meticulous record of all of your changes as you make them in your Sandbox and then painstakingly add them to your Change Set one by one. There's no way to compare the two orgs and then just add everything that's different. As you can imagine, this makes it very easy for orgs to get out of sync with each other.
   
Resources to continue learning:

Salesforce CLI

Salesforce CLI stands for "Salesforce Command Line Interface" and is a much more advanced and accurate way of managing changes between Salesforce orgs. It does require using code, but if you're not a programmer don't freak out! It's easy to learn and well worth the time. In a short amount of time, you won't believe you did it any other way!
  
Salesforce CLI gives you access to one of the most well-used change management tools in the world; GitHub. GitHub is used for tracking changes in software and code. It allows for whole teams of people to be working on the same piece of software, each making their own changes, and then merging all the changes together into one final version which works.
  
Now imagine that you're working in your Salesforce Sandbox org, making updates to fields and profiles. Instead of making a note of these changes to add to a Change Set later, you can "commit" them to a "branch" as you go. Then when you're ready you can merge that entire branch into your Prod org. Every change you can track, merge, or revert. It's far more accurate than Change Sets, and safer as well!
  
Resources to continue learning:

Sandbox Refresh

A Sandbox Refresh isn't a great way to track your Salesforce changes. It's more for an entire overhaul or - you guessed it - refresh of your Sandbox org. All a Sandbox Refresh does is completely override your Sandbox with the current Production org. This can be great for syncing everything between the two orgs, but it can come at a price. If someone was working on a new feature in that Sandbox and you refresh it before they've deployed it....whoops! That entire feature is gone. While these are good to do a few times a year, with the right change management strategy and tool, they shouldn't be a weekly occurrence.
  
You can continue learning about Sandbox Refresh's here:
Back to NextWork Blog Corner