Salesforce

Salesforce Experts on Change Set Limitations

by | November 27, 2018

Salesforce Experts on Change Set Limitations

As a software best practice, it’s customary to do all customizations and 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 the only tool provided by Salesforce natively for the migration and deployment of these changes.

 

You can add various Salesforce components viz Apex Classes, Visualforce Pages, Lightning Components, Profiles, and other metadata in a change set created on a source org. You can then upload this change set into the destination org (Test Org/Prod Org) and click on “validate” to deploy in the destination. If you encounter any error, the errors are reported. If everything is alright, your changes are now live. 🙂

 

Salesforce Change Sets however do not comply with the deployment best practices of modern software development. There is no risk analysis, a lack of visibility into the changes being rolled out for release, no insights into the business impact and associated vulnerabilities, etc. Here below, we will cover these and other shortcomings encountered by Salesforce experts when implementing change sets.

 

How to Clean Your Salesforce Org in 6 Steps

 

Not everything Can Be Deployed

Change sets do not support all Salesforce components. An administrator will thus 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 like our blog
5 Challenges when Deploying New SFDC Changes

———-

 

Delivery Chains Can’t Be Maintained

Let’s say you deploy a change set from dev to QA. All of your QAs verify the workings, and it is ready to be moved to the prod environment. But you can’t move the same change set to prod. You will have to recreate the change set in QA and then push to production. Especially in organizations with multiple test environments, pre-prod, and then prod, you can’t establish a chain when using change sets.

 

The issues that arise in this case include:

  • Increased deployment time
  • The possibility of human error
  • No one-touch continuous deployment

 

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

———-

You might also like our blog
Managing Salesforce Sandbox Changes in Production

———-

 

Adding and Removing Elements Is a Drag

It’s not easy to create large change sets. You have to scroll through various pages if you have thousands of components, state is not maintained during page changes, 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. Phewww!!!

 

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

No Risk Analysis Before Deployment

Change sets lack any risk analysis of changes being deployed. It cannot, for instance, know how critical a change is based on the number of places it is already being used in the app. This means you are unable to communicate risks to the customer beforehand, consequently decreasing reliability and increasing vulnerability of the deployment. Many customers nowadays must resort to risk-identification apps to handle potential risks associated with deployments. Panaya’s Release Dynamix for Salesforce is one such tool that can give you a risk summary/cockpit view of your impending deployments.

 

So, not having proper risk analysis leaves you with:

  • Vulnerabilities and risks during deployment
  • No dependency analysis

 

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

Rollbacks Are Not Supported

Once you deploy a change set to a destination org, you cannot undo the changes if the business demands. This means that the client/business is stuck until you can reverse all the changes in your QA org, recreate a change set, and then deploy back to prod. This can easily lead to loss of business for the client if deployed changes are blocking their core activities. Since change sets don’t have an associated risk analysis, these roll back requests are not scarce.

 

Just one major issue here: No fallback approach if things go wrong.

 

———-

You might also like our blog
Top 10 features of Salesforce Winter ’19

———-

 

Which Components Were Deployed for Which Change?

Unfortunately, change sets cannot answer this question. They are not integrated with leading project management software such as JIRA, Mantis, and Bugzilla. Nor can you 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 on what client request, which is hazardous during backtracking to identify the root cause of an issue.

 

Software such as Panaya’s Release Dynamix for Salesforce offers an easy-to-use UI to be able to scope requirements, associate the components to these requirements, and analyze risks independently. RDx for Salesforce also allows you to associate test cases with each requirement scope; and you can even create automatic test cases in complex requirements.

 

Main issue here: Lack of visibility into changes.

 

How to Clean Your Salesforce Org in 6 Steps - Step 1

 

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. And 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.

So, Why Use Change Sets?

Despite so many drawbacks, admins and developers are still induced to use change sets. This seems incredible given so many constraints and obstructions. How have change sets remained such a prominent tool for Salesforce deployments for over 15 years? We talked with many admins/devs to identify why change sets continue to be used. Here are some of the revelations we found.

Neglect

Neglecting release management best practices might simply seem a quicker option to many. And sometimes we fail to understand the negative impacts it could cause a business.

Assuming Extra Ad-Hoc Work

Change sets are built right into the Salesforce platform. If we use other deployment tools such as GIT with Jenkins, we need to install these locally on a server or buy its cloud-based subscriptions. Many will prefer avoiding any extra ad-hoc efforts when performing deployments.

Lack of Knowledge

Few devs/admins in the Salesforce industry—which has bloomed in the last 10 years—are aware of tools that can help with Salesforce deployments. But they do exist. There are cloud-based Jenkins Solutions and various software vendor apps such as Gearset that help with Salesforce deployments. And even fewer know of risk mitigation and risk planning, which can be achieved via software such as Panaya’s Release Dynamix for Salesforce.

 

———-

You might also like our blog
How to Clean Your Salesforce Org in Six Steps: Step 1

———-

Alternative Options

You most likely agree with many of the limitations mentioned above. And you might have even encountered a few in your own Salesforce deployments and releases. So how can you achieve a more modern and secure release management?

 

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 a deployment tool to deploy Salesforce 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 business impact analysis: This is an often-overlooked aspect of deployments. Tools such as Panaya’s RDx have used technology to drive and calculate the dependencies of change with other changes along with risk calculation (low, medium, high) in order for you to deploy with confidence. RDx 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.

 

Continuous Delivery for Enterprise Applications