The way in which we push changes between Salesforce environments is in the middle of a major shift. For many admins, this can be quite daunting, as it will be their first experience of diving into the development world.
With DevOps clearly being the future from Salesforce’s perspective, change sets are seemingly on their way out (as detailed in our article Salesforce Change Sets vs. DevOps Center). But for many admins, Salesforce change sets are a bridge between the admin and developer worlds – one which wouldn’t be as easy to cross when going straight into something like the DevOps Center. This guide will cover everything you need to know to get started successfully deploying changes from a sandbox to production using Salesforce change sets.
Data vs. Metadata
To understand change sets, you need to know the difference between data and metadata. The simplest way to understand the difference between data and metadata is to think of your Salesforce org like a spreadsheet. The metadata would be the columns in the spreadsheet: (Field name, API Name, Created Date etc.), while the data would be the rows in the spreadsheet. Metadata is data that describes other data.
What Are Salesforce Change Sets?
Change sets are the native way to move metadata customizations between sandboxes and your production environment. For example, if you create a new field in your sandbox, using change sets you can move this field into another sandbox or to production. They only work with metadata, so you can’t move records through environments (for this, you will need a Data Loader tool).
There are two types of change sets. An Outbound change set is created from the org where you have made the customizations. This will then be uploaded to the org in which you want the changes to take place. An Inbound change set is what has been uploaded to that org for you to be able to deploy the changes.
Permissions Needed
There are certain system permissions required to be able to create and manage change sets. In most cases, a user with an admin profile will be creating and deploying the change sets, so the specific permissions are already part of their profile.
If your organization wanted specific non-admin users to use change sets, they will need the following permissions added to their profile or permission set:
Planning Your Change Management
You need a plan for how you manage your changes. It can be simple, like the four-phase approach below. Or it can be more complicated, as shown in this article around the ideal change management process.
Either way, this plan should be documented and communicated well between everyone involved in the process. A diagram of how the changes will be moved between sandboxes would also be a good idea so there is also a visual element to the plan.
Getting Your Org Ready
Before creating your change set, you will need to set up the deployment connection in the target org. This can be done by going to Deployment Settings in setup. If you click Edit next to the sandbox you wish to create the change set in, you will be brought to the following screen:
You will see that there is an option to allow inbound and outbound changes. Inbound changes are those sent from other orgs, while outbound changes are ones you wish to send from this org.
Creating a Salesforce Change Set
Now you’re ready to create your change set. To do this, go into Setup and find the Outbound Change Sets option, then select the new button.
Next, give it a name and description, then save.
You will now be able to add your components to the change set. Once you have added a component the View/Add Dependencies button will no longer be grayed out and you will be able to search for components related to what you have added.
For example, if you add a new formula field to your change set that references another field, that field will show in the View/Add Dependencies section. It is always worth doing this, as if you didn’t add the other field, your deployment would fail if this field wasn’t in the destination org.
One thing to bear in mind here is that the dependent list will show all dependencies whether they are in the destination org or not. Therefore, planning your change set is always recommended, as with the formula field example; if a field being referenced is already in your destination org, you will not need to add it to your change set.
It is worth noting that some components cannot be deployed via change sets. Standard picklist values, sales processes, divisions, and organization-wide email addresses are examples of components not supported via change sets. It is always worth checking if your components can be deployed before creating your change set. If your component is not supported, you will need to manually create it in your production environment.
Uploading Your Salesforce Change Set
Once you have added all of your components to your change set, you’re ready to upload it to your target org. To do this simply select the Upload button, then select the org you wish to upload it to.
Once it has been uploaded, you will receive an email to say you are now able to deploy the change set in your target org.
Please note that once a change set has been uploaded, it cannot be amended. If you need to make any adjustments, you will need to clone the change set and then re-upload it to your target org.
Deploying Your Salesforce Change Set
To deploy your change set, in the target org go into Setup and find the Inbound Change Sets option. Now select the change set you want to deploy. You will see there are three options; Validate, Deploy, and Delete.
- Validate will run a validation over the change set and let you know if the change set is ok to deploy or not. It is a good idea to run the validation first as this will show any errors you may face with the deployment. Going back to our formula field example, if you didn’t add the dependent field, this is where you would be shown an error message.
If you run the validation first and it succeeds, you will then see a Quick Deploy option on the change set which will bypass the validation when actually deploying the change set.
- Deploy will first run the validation and then attempt to deploy the changes.
- Delete will delete the change set. This will mostly be used if you made a mistake in a previous change set and had to clone and upload a different one.
Once you’ve selected to validate or deploy, you will then have the option to choose a test option.
This is only relevant if you are deploying Apex code via the change set, and you can specify the test classes you want to run during your deployment. If you aren’t deploying any Apex, you can select the Default option.
Monitor Your Deployment
Once you have begun deploying your change set, you can monitor its progress by going to the Deployment Status page in setup. Here you will be shown a list of your deployment history. If there are any issues with your deployment, this is where you will find the errors/what has gone wrong.
Considerations
The first thing to consider with change sets are the limitations around profiles; they simply don’t play nicely with them. For many admins, it is much easier to push their customization changes through change sets and then update the profile permissions afterward. For example, they will push a new field through the change set and then update the profile permissions to that field manually in production. Although not ideal, this does give a good way of sense checking a user’s permissions.
That being said, Salesforce is keen to move away from profile-based permissions and into permission set-based permissions. And permission sets are something that do play nicely with change sets.
Another thing to consider is that any changes made through change sets cannot be rolled back. If, like me, you’ve broken some things in production thanks to an ill-thought-out change set, there’s no way to simply roll the changes back unlike with other DevOps solutions.
Summary
In this new age of DevOps-focused development, there are many reasons to no longer see change sets as a worthy comparison. As a tool, this may be true, but as a concept, it isn’t. For many admins (myself included), change sets were their first experience of how development should really be done. Change sets are still a very good way to begin understanding a development process, as you learn to understand how metadata is deployed between different environments, and how component dependencies work. In short, they still matter.