Salesforce Change Sets – Limitations and The Deployment Tools that Bypass them

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. 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. 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 most straightforward 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 mean you’ll need to move changes out of an environment. You must create an Outbound Change Set and point it towards a receiving environment. 

Your Change Set consists of components, and you will h to add every detail you created into your change settings manually. 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 demanding part of Change Set management using the Salesforce deployment tool, as it’s very easy to forget details, even though Salesforce lists some component dependencies in the Change Set interface.

How do I Deploy a Salesforce Change Set?

How to create a change set in Salesforce? You will have to upload your Outbound Change Set for it to become an Inbound Change Set, and go to your destination org to accept your Change Set and deploy it:

This Outbound Change Set 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.

Suppose you encounter any error during the deployment process (and you almost certainly will). In that case, 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 the 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 correctly and ready to be moved to the production environment. But you can’t move the exact change set to prod. You will have to clone the change set, add the dependent components, and 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

Let’s say you create your dev and QA sandboxes from a single production instance. All 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 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 significant 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, speeding 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 cannot communicate risks to your end-users beforehand, decreasing reliability and increasing deployment vulnerability. Many customers must now resort to risk-identification apps to handle potential deployment risks. Panaya ForeSight for Salesforce is one deployment 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. Most 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 change setting manually. 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 deploy 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 significant 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. 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 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 is the 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.

Change Sets face problems of:

• Uncertainty in deployments.
• Incompatibility with best practices.

The Pros and Cons of Change Sets

Despite many drawbacks, admins and developers are still induced to use Change Sets. Here’s a quick summary of the pros and cons:

Pros:

• No additional cost
• Declarative deployments can be managed with clicks
• Abundant Supporting Documentation

Cons:

• 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
• Challenging 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

Alternative Options

What are the different ways of deployment in Salesforce? If you’ve ever managed a Salesforce deployment, you have likely experienced 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 more modern and secure release management?

You could create your version control and impact analysis systems, or you can leverage the work of pros before you.

Source Control, Jenkins:

First, 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. It would be best if you also implemented 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.

Secondly, you need to explore risk assessments and impact analysis. Tools such as Panaya ForeSight for Salesforce have used technology to drive and calculate change dependencies with risk identification so you can deploy confidently.

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 clearly understand 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, but a successful deployment doesn’t have to fail because of its shortcomings. By learning about the common issues associated with Salesforce Change Sets and 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.