As a software best practice, it’s customary to do all development on a dev org, push these changes to a test org, and then move all these customizations to an actual live/production org once testing is done. The process of moving changes is called deployment, and Salesforce Change Sets are one of the only deployment tools in Salesforce natively for the migration and Salesforce deployment process of these changes.
Salesforce Change Sets, as part of the Salesforce deployment strategy, however, are famously despised by Salesforce developers for their clunkiness, and often do not comply with the deployment best practices of modern software development or even Salesforce deployment best practices.
The Changes Sets Salesforce provides do not offer robust risk analysis, they lack visibility into the effects of changes being rolled out for release, they provide no insights into the business impact and associated vulnerabilities, and they have no concrete way to catalog your changes without heavy manual management.
But don’t despair! Your Salesforce development project doesn’t have to rely entirely on the peculiarities of native Salesforce Change Sets.
Below, we will explore what Change Sets are and how to deploy using Change Sets in Salesforce, their common shortcomings, their pros and cons, and alternative options to improve your change management.
What Are Salesforce Change Sets?
In their simplest terms, Salesforce Change Sets are the mechanism by which changes from one Salesforce environment can be pushed into another Salesforce environment. Salesforce change set best practices means you’ll need to move changes out of an environment. You must first create an Outbound Change Set and point it towards a receiving environment.
Your Change Set consists of components, and you will have to manually add every single component you created into your change set. A component can be various components of Salesforce development like Apex Classes, Visualforce Pages, Fields, Lightning Components, Profiles, and other metadata.
Adding components to a Change Set is unquestionably the most onerous part of Change Set management using the Salesforce deployment tool, as it’s very easy to forget components, even though Salesforce does list some component dependencies in the Change Set interface.
How do I Deploy a Salesforce Change Set?
This Outbound Change Set then becomes an Inbound Change Set to the destination org. The Inbound Change Set must be deployed in the destination org, and the changes must be validated and pass Apex test coverage (if relevant) before they can become live.
If you encounter any error during the deployment (and you almost certainly will), errors are thrown and you must discern where your Change Set went wrong and diagnose how to fix your initial Outbound Change Set…and then reinitiate the Outbound Change Set to Inbound Change Set process.
If your destination org accepts your Inbound Change Set, and you’ve reviewed, validated and deployed, your changes are now live.
Salesforce Change Set Limitations
Now that you’re familiar with the basic concepts of creating and deploying Change Sets, it is important to be aware of common ChangeSet Salesforce issues.
1. Not Everything Can Be Deployed
Change Sets do not support all Salesforce components. An administrator will, therefore, have to perform some changes manually. Some examples of components not supported include standard picklist values, sales processes, divisions, organization-wide email addresses, etc. Because of this limitation, an organization can face issues of:
- Increased deployment time
- Manual intervention
- The possibility of human error
You might also want to check out our blog post: 5 Challenges when Deploying New SFDC Changes
2. Delivery Chains Can’t Be Maintained
Let’s say you deploy a change set from dev to QA. All of your QAs verify your design is working properly, and it is ready to be moved to the production environment.
But you can’t move the same change set to prod. You will have to clone the change set, add the dependent components and then reupload it. Especially in organizations with multiple test environments, pre-prod, and then prod, you can’t establish a chain when using change sets.
3. Only Connected Orgs Are Supported
Here, let’s say you create your dev and QA sandboxes from a single production instance. All of these are connected orgs, and now you can use change sets to move changes from dev to QA to prod. If the same product/app is used in multiple organizations, each having its own production instance, you cannot make a connection from prod to prod.
This is a common scenario in healthcare where multiple hospitals use the same underlying Salesforce product but different production orgs.
With this problem comes:
- Increased deployment time
- Lack of feasibility and reusability
- Redundant work
4. Adding and Removing Elements Is a Drag
It’s not easy to create large change sets. You have to scroll through several pages if you have thousands of components, and you can’t add different types of components simultaneously.
To make matters worse, if you mistakenly add some components and then need to remove them, you must do it one by one. As an alternative, many admins resort to browser extensions to resolve this issue, which speeds things up. The problem with this, however, is that these extensions take control of your data/code, which might be a breach of your organization’s compliance.
Drawbacks here include:
- Very slow to create/edit (frustrating)
- Possible compliance breach if browser extensions are used
5. No Risk Analysis Before Deployment
Change sets lack any risk analysis of changes being deployed. This means you are unable to communicate risks to your end-users beforehand, consequently decreasing reliability and increasing vulnerability of the deployment.
Many customers now must resort to risk-identification apps to handle potential risks associated with deployments. Panaya ForeSight for Salesforce is one such tool that can give you a risk analysis view of the impact of your impending deployments.
So, not having proper risk analysis leaves you with:
- Vulnerabilities and risks during deployment
- No dependency analysis
6. Not Integrated with Version Control Systems
Change sets cannot be created automatically based on revision numbers from Git/SVN. A majority of organizations use Git/SVN to serve as their source of truth when multiple developers are coding in the same system.
However, since change sets are not integrated with source control, it takes extra effort to identify what changes were done and how to push each to change set manually one by one.
If multiple dev sandboxes are used, a developer might overwrite changes of another developer, as the source of truth for change sets is Salesforce org, not Git/SVN. A solution is to use Jenkins or other cloud-based solutions to do the deployment using Git/SVN as the source of truth.
Problems that arise here are:
- Error-prone deployments
- The extra effort required to build change sets
7. Rollbacks Are Not Supported
Once you deploy a change set to a destination org, you cannot undo the changes if needed. This means that your end-users are stuck until you can reverse all the changes in your QA org, recreate a change set, and then revert the change manually in prod.
Deployment failures and downtime can easily lead to loss of business if deployed changes are blocking their core activities.
Just one major issue here: There’s no fallback approach if things go wrong.
8. Component Changes are Hard to Track Down to a Specific Change Set
Unfortunately, change sets are not integrated with leading project management software such as JIRA, Mantis, and Bugzilla, and you can’t create component groups within a change set, since all components of all changes come as a single list.
This means you never get visibility into which components were modified per request, which is hazardous during backtracking to identify the root cause of an issue.
Software such as Panaya ForeSight for Salesforce offers an easy-to-use UI to be able to scope requirements, associate the components to these requirements, and analyze risks. This allows you to understand, before the deployment process in Salesforce, the full scope of your project and the exact areas of impact so you can efficiently plan your project.
The main issue here: Lack of visibility into changes.
9. Not Built On Modern-Day SDLC Concepts
The SDLC concepts of CICD, risk mitigation, and delivery certainty are a ways away. Change Sets are not compatible with continuous integration/continuous delivery. And it certainly doesn’t consider the business impact that changes might lead to in production. Since there are no one-click deployments, and we cannot establish a delivery chain, deployments are uncertain. These are all different from present-day software development best practices.
So here you face problems of:
- Uncertainty in deployments.
- Incompatibility with best practices.
The Pros and Cons of Change Sets
Despite so many drawbacks, admins and developers are still induced to use Change Sets.
How have Change Sets remained such a prominent tool for a Salesforce deployment for over 15 years? Here’s a quick summary of the pros and cons:
- No additional cost
- Declarative deployments can be managed with clicks
- Abundant Supporting Documentation
- Adding components is cumbersome, time-consuming and confusing
- High risk of deployment failure
- Some features aren’t even supported with Change Sets
- Does not fully follow CI/CD best practices
- No roll-back functionality
- Limited risk analysis capability
- Only Connected Orgs are Supported
- Difficult to determine which Change Set an enhancement came from
- No connection between enhancement planning and Change Sets
- Overall Deployment is insanely Time Consuming and Easy To Break
What are the different ways of deployment in Salesforce? If you’ve ever managed a Salesforce deployment, you have likely experienced firsthand some of the inefficiencies of native Change Sets. And you might have even encountered issues in your deployment process in Salesforce and releases not listed here. So how can you achieve a more modern and secure release management?
You could create your own version control and impact analysis systems yourself, or you can leverage the work of pros who have gone before you.
Source Control, Jenkins:
First off, you can use a source control system such as Git/SVN to manage your source of truth. This eliminates the limitations of code-merging and promotes better code-tracking. You should also implement Salesforce deployment tools to deploy components from these source control systems.
Jenkins is one such Java program that contains packages for Salesforce integration. You can configure it locally or use a cloud-based solution.
Change Intelligence with Impact Analysis, Panaya ForeSight:
Secondly, you need to explore risk assessments and impact analysis.
Panaya ForeSight is one of the best Salesforce change management tools to allow developers, admins and architects to plan their Salesforce changes while keeping potential impacts on the existing system in mind. By running a Risk Analysis for a proposed change before a requirement is even fulfilled, developers can have a clear understanding of areas of potential breakage, long before their code needs to be pushed into a higher environment.
Panaya ForeSight also offers deep insight and impact risk into every scoped component, allowing for easier management and assignment of all development and release-related tasks. The impact graph provides a clear visualization of the dependencies within the Salesforce Org and how they relate to a planned change.
ForeSight allows test cases to be associated with individual changes so that you can assess whether high-impact stories have been tested rigorously. And this means you—and your bosses—can sleep better.
Keep Calm and Change Set On
Salesforce Change Sets can be painful to use, but a successful deployment doesn’t have to fail because of their shortcomings.
By learning about the common issues associated with Salesforce Change Sets and by careful pre-planning, you can prepare yourself for a successful Salesforce deployment strategy. Leverage existing technologies like Panaya ForeSight before you plan your deployment to make your Change Set management process a success from the start.