Many Salesforce teams are still using change sets to move metadata from one org to another. Unfortunately, change sets are hard to manage and can significantly slow down your releases.

In this article, I will list the top six change set "features" and explain why they are so problematic for Salesforce teams. I will, of course, show you a better way, using Salto :)

‍

Change Sets don’t know what has changed in your org

Let's say you do a lot of work in your sandbox org.

#1

Two new custom fields

#2

One modified apex class

#3

A change in a flow

#4

A new email template

Between emails, lunch breaks, etc., it's easy to forget exactly which changes you've made.

When you first create the change set, it'll show you a list of all the metadata in your org. It has no idea what changes you've made.

Unless you've written down your changes (or you remember them), it's easy to forget one or two, which will cause your deployment to fail, or worse, to succeed with half the functionality.

Because Salto deployments are based on comparing two orgs, you can immediately see everything different between them, which naturally includes those changes you've made.
‍

This way you can quickly grab those changes and deploy them to your target org.
‍

You can only select one metadata type at a time

Let's say you want to deploy two fields and three email templates. The change set UI forces you to select only items of one metadata type at a time. So you'll have to select the fields, click save, then select the templates and click save again. If you are deploying five different metadata types, that's a lot of clicks.

With Salto, you can select multiple metadata types simultaneously with just one click.

You can also filter across all metadata types so you can find exactly what you need very quickly.

You cannot see the difference between the source and target orgs

If you are modifying existing metadata, change sets don't give you a chance to see what that metadata looks like in the target org. Instead, you have to log in to both orgs, check the differences manually, and once you deploy, confirm that the intended changes were made successfully.

With Salto, you can see the difference between the two orgs, so you know exactly what will be the result of the deployment.
‍

You cannot deploy specific sections of a Profile

When you include a Profile in a change set, all the system permissions get deployed to the target environment, even if you just included the profile because of a new field (in other words, you wanted to deploy the field and its Field-Level Security (FLS)).

If you are not familiar with this scenario, let me give you an example:

Suppose that you create a new custom field, and you enable the field for one profile (this is done by modifying FLS on that profile).

Now, to deploy the field and its FLS, you need to include both the field and the profile in the change set.

If the profile in the source org has different system permissions than the target org, those system permissions will be overwritten to match those ones in the source org.

This means that if the "Convert Leads" system permission was enabled in the target org but not the source, the change set would disable "Convert Leads" in the target org. This could prevent all your sales reps from converting leads...not fun!

You may be wondering why the permissions might be different in the first place. Good question. This could happen if another admin enabled "Convert Leads" directly in production, so your sandbox doesn't have this permission enabled on the same profile.

In any case, with Salto's unique approach to org comparison, you can be very selective about which parts of a profile you want to deploy, be it system permissions or just FLS.
‍

You cannot deploy CPQ data (or any other configuration data)

Salesforce CPQ uses custom objects as configuration data. This includes Search Filters, Configuration Rules, Price Rules, etc. While these are stored as records, they actually represent the configuration of your CPQ implementation.

Because  CPQ is not a native Salesforce solution (e.g it's a managed package that sits on top of Salesforce), these rules cannot be configured via the Setup menu and are not available to deploy through change sets.

This means that you cannot deploy CPQ configuration and other metadata, and you must use special tools for this or deploy the data with the data loader.

In Salto, we treat CPQ data as metadata, and they can be deployed in the exact same way you can deploy metadata, and it can be deployed alongside metadata.
‍

This allows you to have a consistent process in your deployments, and this can be expanded to other data in the org, not just CPQ.

You cannot tell how much out of sync your orgs are

With change sets, you move metadata from A to B, but you don't get visibility on whether those two orgs are in sync and, if not, how much out of sync they are.

This means your change set deployment can finish successfully, but the actual feature doesn't work in the target org because some related metadata or configuration is different from what you expected.

Because Salto's deployments are based on org comparison, you get a full picture of the differences between both orgs. You can then be very selective about which metadata items you want to sync. The more in sync your orgs are, the more likely your deployments are to succeed.
‍

‍

You cannot assess the impact of your changes

This is not exactly a change set limitation but more of a Salesforce problem overall. For example, if you are deploying a change to a custom field or apex class with change sets, you cannot foresee any potential impact of said change (i.e will the change break any flows or validation rules?)

With Salto, you can easily see where any metadata type (not just fields) is used in the org. This can help you decide whether to go ahead with that change or maybe do some more investigation about its potential impact.
‍

You cannot dynamically add dependent elements

Change sets let you get dependent elements but only one level down. With Salto’s deployment, you can choose an element to deploy, find its dependent elements, include those in the deployment, and repeat, until you find the last dependent component.

This ensures that your deployment is more likely to succeed the first time, rather than it being a trial and error exercise.
‍

This is the part in the article where I would try to convince you not to use change sets, but if you read this far, I’m confident you now know a better way :)

Until the next post.

‍