Profiles and permission sets are renowned for being difficult to deploy, so getting ready for permissions on profiles to be retired is striking fear into the heart of change sets users throughout the ecosystem. What makes deploying these types of changes so challenging? And is there a better way to get your permission sets in order before the transition?
The difference between profiles and permission sets
Currently, profiles define what all users of a particular type can access within Salesforce, determining what data they can view and what actions they can carry out.
Because each user can only have one profile, permission sets were introduced to allow greater access levels for specific users without having to change their assigned profile.
The problem with profiles
Profiles are notoriously difficult to manage, mainly due to their size. Every field in every object has a corresponding fieldPermissions entry in every profile. A large organization can have 100 profiles and 30,000 fields, which results in 3 million field permissions entries before even considering permission sets.
Plus, it’s not possible to deploy profile entries for fields that don’t exist in the target, so you need to align the metadata between your orgs before you can begin to deploy profile differences.
In fact, deploying profiles can be so tricky that many developers and admins we’ve spoken to avoid deploying them all together. Instead, teams manipulate xml by hand, or manually modify the profile configuration in production. Not only is this an inefficient use of time, it’s also very error-prone and can compromise org security.
Salesforce are set to retire profiles
Given the difficulty users have experienced with managing profiles, permission sets have long been viewed as the way forward for Salesforce teams looking to adopt DevOps. So it’s unsurprising that Salesforce recently announced the end of life (EOL) for permissions on profiles in Spring ‘26.
While profiles won’t be retired completely, they will look very different following the Spring ‘26 update: permissions that used to live on profiles will be shifted to permission sets, including object permissions, apex classes, visual force pages and more.
While Salesforce has given a long window for teams to prepare for the shift away from profiles, for teams who deploy permission sets with change sets, this can be a daunting prospect.
Deploying permission sets with native change sets can be just as tricky as profile deployments. There are two key frustrations:
All components referenced by the permission set must be included in the change set. For example, if I have created a permission set that grants access to a custom object, I have to remember to include that custom object in the change set too, even if it already exists in the target. If I forget to add the custom object, the object and field permissions will be missing from the permission set once deployed.
Permission sets get deployed as a unit. This frustration is common among tools beyond change sets too. With most tools, permission sets are deployed as a whole unit rather than being merged with the existing permission set in the target. So if you deploy a permission set from a source org that has fewer objects or installed features than your target org, access for all the missing components will be turned off in the target org.
If you’re ready to get your permission sets in order but don’t want the headache of native tooling, Gearset is here to help with its metadata deployment solution that allows you to easily deploy permission sets.
How to deploy permission sets and permission set groups with Gearset
NOTE: Gearset’s comparisons have had an upgrade! We’re in the process of updating all our blog posts with the new UI images, but in the meantime you can find out more here.
Permission sets and permission set groups can be deployed (or deleted) as part of the click-driven deployment flow that Gearset already offers. You can sign up to a 30-day free trial and follow along below.
See the differences in your permissions across orgs
Simply select your source and target for the deployment and Gearset will present all the changed, new, and deleted components in your orgs as a side-by-side diff including your permission sets and groups.
See the differences between environments at a glance and click on any component to view the XML. Gearset also highlights all dependencies, so you can make sure you’re including everything you need in your deployment.
Successfully deploy your permission sets every time
Once you’ve built your deployment package, Gearset will run static code analysis as well as a range of problem analysers. Problem analysis will pick up on any missing dependencies plus other common issues that can cause deployment failure. But there’s no need to rerun your comparison and build the deployment package again — simply select the suggested fixes and Gearset will automatically update your deployment package for you.
For example, if I tried to deploy a permission set group without including new permission sets that were not already in the target, Gearset would flag the issue to me in advance of the deployment.
Run your deployment with confidence
The deployment summary page will give an overview of all components to be deployed and you can connect to your issue tracking provider to automatically update a ticket (or multiple tickets) with the information from your deployment.
It’s important to note that Gearset will intelligently merge this deployment with your existing permission set in the target. The comparison that gets run between your source and target orgs before a deployment means that Gearset can see the state of the permission set in the target and merge just the selected components during the deployment. So if there are fewer objects or installed features in your source, don’t worry! Gearset will add the new elements of your permission set to the target without turning off the permissions for components that don’t exist in the source.
Once you’ve pressed ‘Deploy now’ and the deployment has run, Gearset will give you a summary of the deployment as well as a comprehensive downloadable report for auditing. This information will also be saved under the deployment history tab and can be accessed at any time.
Rollback a permission set deployment
Even with the best planning, sometimes deployments need to be undone. But don’t worry — that’s covered too! By heading to the deployment history tab, you can select any deployment to rollback.
The rollback workflow flow is the same as a regular deployment — just select the components you want to roll back to their pre-deployment state (meaning you can do a full or partial rollback), and Gearset will do the rest.
Get ready for Spring ‘26
Although Spring ‘26 seems like a long time away, getting your permissions in order ahead of the game is the best way to ensure a smooth transition. If you’re keen to prepare but are daunted by the prospect of using change sets for your permission sets deployments, arrange time with one of our experts to see how we can get you up and running with painless permission set deployments.
Or you can watch our video on how to seamlessly transition from Profiles to Permission Sets in Salesforce.
