A better way to deploy profiles and permission sets
Andrew Hunter on October 20th 2016
Profiles and permission sets are renowned for being difficult to deploy. The thought of migrating these types of changes strikes fear into the heart of Change Sets and Ant users the world over. What is it that makes deploying these types of changes so challenging? More importantly, is there a better way?
The problem with profiles
In the traditional workflow, profiles and permission sets can require a considerable amount of manual work to get to a state where they can be successfully deployed to a target organization. The main reason they are so tricky to deal with is one of 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. The real difficulty arises from the fact that it’s not possible to deploy entries for fields that don’t exist in the target, so if there are any profile differences between the source and target organizations, it’s necessary to wade through this huge amount of data to manually get it into shape for deployment.
It’s not uncommon to talk to developers and admins who eschew tooling altogether and either spend a significant amount of time manipulating xml by hand, or migrating changes directly by tweaking the target org configuration manually. Not only is this laborious and uninspiring work, it’s also error-prone - naturally this was one of the earliest problems we wanted to address with Gearset.
How Gearset helps
Rather than treating profiles as single, contiguous xml files isolated from the rest of your org configuration, Gearset understands the shape of the target organization. Specifically, we break the profile up into its constituent components and associate each of those
fieldPermissions entries back to the fields they refer to. This means that when Gearset is asked to deploy a new profile, it checks which fields will be present in the target org, and it only deploys those corresponding profile entries. You no longer need to manually exclude irrelevant permissions by hand.
When it comes to modifications to existing profiles, these sorts of changes are often related to adding or changing objects, so we picked an approach to support that workflow. Changes to profiles are grouped by the object that they affect, so that when something like a field or an Apex class is deployed, the permissions relating to it can all be deployed alongside it with a single extra click. These changes can be found by searching for the ‘Permissions for’ rows or by clicking on the expansion arrow next to an object and under the ‘Profiles and permissions’ section.
We’ve been looking into how this feature has been used since it was released and realise that there are other workflows surrounding profiles and permission sets that need to be dealt with - in particular that it’s sometimes necessary to deploy a changed profile as a whole. We’re working on a new UI for profiles in Gearset that will make this kind of deployment much easier - expect these changes to begin to appear in the application over the next few months.
Had enough of manually deploying profiles? Head to https://gearset.com and try 30 day free trial.