Last Updated on December 25, 2022 by Rakesh Gupta
Salesforce change sets are widely used today to move changes from sandbox to production. And why wouldn’t they still be used? In many cases, they provide an easy way to deploy metadata without knowing Git, XML, etc.
But once your project or team gets to a certain size, you’ll start experiencing the pain of Salesforce change sets.
In this article, I’ll walk you through the challenges I’ve experienced with them and what I think the solution to this problem is.
Change Sets don’t know what has changed in your org
Let’s say you do a lot of work in your sandbox org for an upcoming project. So you:
- Create two new custom fields
- Modify an existing apex class
- Change the logic in a flow
- And create 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.
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, select the templates and click save again. If you are deploying five different metadata types, that’s a lot of clicks.
If you are deploying a lot more than that, you can easily spend half an hour building your change set.
You cannot see the difference between the source and target orgs
If you are modifying metadata that already exists in the target org, change sets don’t allow you to see what that metadata looks like in the target org.
This means you can’t tell how your changes will impact the target org. You can’t see the differences.
Instead, you must log in to both orgs, check the differences manually, and confirm that the intended changes were made successfully once you deploy.
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 unfamiliar with this scenario, let me give you an example:
Suppose you create a new custom field and 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 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.
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 represent your CPQ implementation’s configuration.
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 configuration data, and you must use special tools for this or deploy the data with the data loader.
You cannot tell how much out of sync your orgs are
With change sets, you move metadata from one org to another, 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.
You cannot dynamically add dependent elements
Change sets let you get dependent elements but only one level down.
This means that if you add a flow that uses a subflow, the change set UI will let you know that you should also add that subflow. But if that subflow depends on other metadata like custom fields, custom labels, or other subflows, you’ll never know (unless you remember or wrote it down somewhere).
The solution
This sounds all too negative but don’t despair. There’s a solution to all these problems!
The solution is to end your relationship with change sets, as hard as it can be.
Once you are done with change sets, you need to look for a DevOps vendor. Many different DevOps vendors can make the experience of deploying changes much better.
Salto is not yet another deployment solution. We have a unique approach to Salesforce metadata, and we carefully studied all the issues I mentioned above and fixed them 😉
Let me share a few examples:
Org comparison and deployment
Salto’s deployments are based on org comparisons, so you only see that which is different in both orgs, and you can select as many types as needed in one go.
Also, our new diff view helps you see differences between orgs in a simple document-like format.
Rollback to previous versions
You can easily track everything in Git, which lets you see prior versions of your Salesforce org and even rollback to an older version.
Don’t forget your dependencies
Salto will let you know if your selected metadata has dependencies that are required. This guarantees your first deployment attempt is your only deployment attempt!
Deploy and track your CPQ data
Salto can also help you deploy CPQ data alongside your metadata while keeping track of everything in Git Salesforce | Deploying CPQ data and metadata
And there’s a lot more!
But don’t take my word for it; you can sign up for a 30-day trial and start deploying like a boss today!
Formative Assessment:
I want to hear from you!
What is one thing you learned from this post? How do you envision applying this new knowledge in the real world? Feel free to share in the comments below.
