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

Let’s talk about Salesforce change sets

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 send customizations to an actual live/production org once testing is done. This process 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.

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. We explore 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. 

Change Sets consist of components, and you will have to add every detail you created into your change settings manually. A component can be part 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 dependent components in the Change Set interface.

How do I Deploy a Salesforce Change Set?

Upload your Outbound Change Sets for them to become Inbound Change Sets, and go to your destination org to accept your Change Sets and deploy them:

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 pass both the validation process and Apex test coverage (if relevant) before they can become live.

When you encounter an error during the deployment process, you must discern where your Change Set went wrong and diagnose how to fix your initial Outbound Change Set. 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, gone through the validation process, and deployed, your changes are now live. 

Salesforce Change Set Limitations 

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 of those which are  not supported include standard picklist values, sales processes, divisions, organization-wide email addresses, etc. As a result, an organization can face various issues:

• 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 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 simultaneously. To make matters worse, if you mistakenly add 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

Deploying  change sets to a destination org is final, 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.

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.