Salesforce change sets have enabled admins to easily move changes from Sandbox to production for many years. Despite the explosion of DevOps products in the last couple of years, I know from experience that many admins still use change sets – I met lots of them at Dreamforce ‘22.
During these conversations, I realized admins knew there were limitations to change sets but didn’t necessarily know what those limitations were. Unfortunately, they had got used to working around them.
Don’t get me wrong, change sets are suitable for many use cases, but as you’ll see, it only takes a mid-size project to start experiencing the pain that comes with them. To help illustrate this, we will learn from a fictional Salesforce Admin working on a fictional Salesforce project.
A Story About Change Sets
Sagi O’Bracha is the Salesforce Administrator at Falafel Consulting Ltd, a mid-sized company in Dublin, Ireland.
For the past two months, Sagi has been working in her personal Sandbox on a project to revamp opportunities by introducing flows that will guide users on creating opportunities, closing them, and upselling them.
The time has come to deploy all these changes to the UAT Sandbox, so Sagi creates a change set in her Sandbox. However, when it comes to adding metadata to the change set, Sagi has a realization: she’s made so many changes in the past two months that she doesn’t remember them all. The change sets UI displays all the metadata, but not whether they have changed or not.
It turns out that change sets don’t know what has changed in your org recently. There’s no way to filter the component list and it only shows the changes made in the past two months.
After going through her notebook, Sagi thinks she has an accurate picture of what metadata she changed, so she adds that to the change set. Unfortunately, in doing so, she finds herself clicking back and forth between multiple component types. She learns that she cannot add components of multiple types simultaneously.
As it turns out, change sets don’t allow you to select components of different metadata types at the same time.
Two hours have passed between doing extra clicks and checking her notebook for clues about what metadata had been changed. She finally gets to the last element, an existing record-triggered flow, to which she added new logic. When she adds this component to the change set, a thought appears in her mind:
What if my colleague, Pablo, has made changes to this flow in UAT? I remember he was working on it too. If he did make changes, how can I see the impact of my changes?
And that’s how Sagi learns a terrible truth about change sets. She can’t see the differences between a component in her Sandbox and the same component in the target Sandbox. She has to manually log in to UAT, open the flow on another screen, and spend some time comparing them by hand.
The day has ended, and Sagi still hasn’t deployed those changes. So she’s lost a whole day of work.
Fortunately, the next day she thinks she’s added all the metadata, including fields, flows, and profiles. Finally, she’s ready to upload the change set to UAT!
But when she attempts to deploy the change set, it fails.
The error states there’s a missing reference to a flow called subflow_oppty_calc. Sagi is confused by this error because she remembers using the View/Add Dependencies button to add all the dependencies to main_opportunity_flow, a big flow that uses multiple subflows.
After some research, she realizes that subflow_oppty_calc is a subflow of another subflow, so it wasn’t shown in the dependencies section.
And so Sagi, frustrated, learns yet another truth about change sets. They only allow you to add direct dependencies. Metadata dependencies of related components are not shown.
Sagi gives up for the day.
The next day, Sagi returns to the change set and adds the missing flow. Then she uploads it again and attempts to deploy it. This time, it succeeds!
Sagi is filled with joy and sends a Slack message to her business partners. Finally, the functionality is ready for UAT testing (two days late, though)!
UAT testing goes smoothly, and eventually, she deploys all the changes to production. But not even two hours have passed since the production deployment, and she’s getting flooded with Slack messages from the sales reps: “We can’t convert leads!”
Sagi is now very frustrated and confused. What went wrong? What could she have done to prevent sales reps from converting leads?
After spending all morning googling, she realizes that profiles and change sets don’t play along. She had added the profiles to the Profile Settings section of her change set.
She had done this because she had created some new fields and wanted to migrate their field-level security. Sagi didn’t know that when you add a profile to a change set, system permissions are overridden in the target org, even if you didn’t intend to.
What a nightmare! Sagi ends the week frustrated and tired, determined to find a better solution to deploy changes between Salesforce orgs.
The Issues
- Change sets don’t know what has changed in your org recently.
- They don’t allow you to select components of different metadata types at the same time.
- You can’t see the differences between the same components in different Sandboxes.
- Change sets only allow you to add direct dependencies. Metadata dependencies of related components are not shown.
- Change sets override system permissions in the target org, even if you didn’t intend to.
The Solution
Did the above story sound familiar to you? Have you been there? I wouldn’t be surprised, I’ve experienced every one of these issues myself. So how do we solve this?
The solution here is to end your relationship with change sets, as hard as it can be.
Salesforce’s DevOps Center is the official replacement for change sets, and I’m excited to see what the future holds! While DevOps Center is a step in the right direction, sometimes you need a much more comprehensive DevOps solution.
Salto is not yet another deployment solution. We have a unique approach to Salesforce metadata, and we carefully studied all of the issues I mentioned above and fixed them.
For example, Salto’s deployments are based on org comparisons, so you only see what 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.
And there’s a lot more!
But don’t take my word for it; you can sign up today for a 30-day trial to see how, in this case, the grass is indeed greener on the other side.
Final Thoughts
Although Salesforce change sets have enabled admins to easily move changes from Sandbox to production, there are limitations that people have been working around for years. It’s time to avoid the pain and switch to DevOps Center – and Salto can help make all your changes manageable and hassle-free.