Change sets can be a powerful tool for implementing updates to your Salesforce org. But they do have some limitations. Here’s the lowdown on Salesforce change sets, and four best practices to help you deploy change effectively.
What is a change set in Salesforce?
A change set allows you to transfer changes from one Salesforce environment to another. The change set is made up of customizations, features, and components that are packaged together. When you create a change set, you manually add each component to the set, and then upload it to the target environment.
See the impact of Salesforce changes before you make them.
Try Sonar Free
How do I deploy a change set in Salesforce?
To create a change set, the first step is to create an outbound change set from the setup menu. Add individual components to your change set. This is a particularly tedious task, and if you forget to add dependent components, your change sets may fail to deploy in the target environment.
Once you’ve completed that process, upload your change set to the environment you want to send it to. Uploading a change set is not equivalent to deploying it. There are still a couple more steps to take.
Next, you need to validate your change set. The validation process checks for errors, such as missing profiles or fields. Once the validation is complete, and issues have been remedied, you can deploy the change set.
Best practices for improving Salesforce change sets
Salesforce change sets have a lot of shortcomings. Unfortunately, there’s no way to completely rely on change sets to perform all of the change management projects you need to. For starters, you’re limited in what you can change since change sets don’t support all Salesforce components. Standard picklist values, organization-wide email addresses, security updates, and other components must be updated manually. And some teams prefer to make some changes manually, like profiles and permissions, because they find it easier than using change sets for those elements.
Salesforce also doesn’t provide the functionality you need to track changes on a granular level. If you’ve ever tried to track a changed component and tie it to a particular change set, you’ve probably found yourself disappointed. Salesforce tracks all component changes as a single list. To address these limitations, we recommend you implement the following best practices:
1. Plan change sets deployments on a schedule
While you may feel pressured by your leadership or by users to deploy changes whenever they need them, that approach can actually be counterproductive. When you make changes outside of a regular schedule, you’re more likely to make mistakes or cause unintended errors downstream in your other processes or systems.
Following release management practices will prevent you from forgetting critical dependencies, failing to communicate potential changes to users, and rushing through the process. When you deploy change sets as part of regularly scheduled maintenance, you have a framework that allows you to think the process through and ensure you’re communicating with all stakeholders.
2. Document your changes
Since Salesforce is limited in how well it tracks change sets, you should have your own separate documentation for any changes you make. Plus, since you’ll have to make some updates manually, you need a centralized location where you keep a log of those changes as well.
3. Test before and after deployment
The validation process isn’t required to deploy change sets. Because your Salesforce org is locked (in terms of making setup and metadata changes) when you validate a change set, you have the option to skip that step. However, if you do choose to forego validation, it’s important to perform a meticulous quality assurance process after deployment. Even if you perform a test in your sandbox environment, it’s possible that it somehow fell out of sync with your production environment. The only way to be sure is to perform a thorough evaluation.
4. Implement a Change Intelligence solution
Anytime you need to make a change in Salesforce, it’s a nerve-racking experience. For all of their benefits, using change sets does come with its own share of pitfalls. The limited capabilities and lack of functionalities can be frustrating, especially when you manage a large, complex sales org. To augment Salesforce’s existing features, consider adding a Change Intelligence solution like Sonar to your tech stack.
Change Intelligence enables you to see the impact of change before you make it. Salesforce impacts so many other tools in your tech stack. A change intelligence tool that lets you see which automations and processes will be affected before you deploy change can prevent costly, time-consuming errors that may not be captured in the validation process.
A Change Intelligence tool can also automatically document your updates. The right solution will improve and streamline your change management projects, allow you to overcome the limitations of Salesforce’s native change sets, and continually evolve your org with ease.