DevOps in Salesforce: Considerations for your deployments
Welcome to our fourth post in a series about building an effective Salesforce deployment pipeline that your whole team will love. Our first post introduced DevOps in Salesforce and our second covered the planning aspects to be considered. In our previous post, we looked at the implementation of a pipeline. This post describes some considerations for Salesforce deployments.

Written by Aaron Allport and Stuart Grieve

Effectively deploying profiles and permissions between environments

Profiles are “unique” in how changes are migrated between environments because Salesforce will typically take the delta of changes in the profile that pertain to the artifacts being deployed. This, therefore, means that it is incredibly hard to keep profiles in-line across environments without the use of a dedicated tool to perform comparisons against profile extracts.

Profiles have always been a challenge. I’ve spent more time than I’d like to admit with two monitors trying to compare profile markups to validate changes as part of releases.



— Martin Gardner, Solution Principal

It can quickly become infuriating when managing a profile in the repository (that is the source of truth) and seeing an entirely different result than expected after a deployment. Additionally, profiles in the repository need to be incredibly large as they need to contain explicit true/false values that pertain to the various settings and object/field security. This is necessary as these permissions change throughout the build of the configuration and code in any Salesforce project. Since the release of SFDX, Salesforce has advocated the use of Permission Sets, as these are immutable and explicit, yet more granular and manageable for a specific set of permissions. Whilst profiles won’t go away, there is a new way or reliably managing user permissions across different environments.

Only use profiles for what cannot be contained within a permission set

Salesforce Profiles contain a lot of information. Some of this information such as login hours and allowed IP range access cannot be defined in a Permission Set, and therefore needs to remain in a Profile. This Profile-specific information is the ONLY information that needs to reside in a profile. Given the nature of Permission Sets granting additional access, the default state for a given profile is no access to anything. It would be prudent to create this “no access” profile at the earliest stages of a project from which additional profiles can be created for each business role. By combining Profiles and Permission Set Groups (explained below) that are in-line with one another, automation can be applied to the assigning of permissions. With the immutable permission-sets that are contained within Permission Set Groups and aligned to a Profile (and therefore job function), permissions can be reliably managed at the source in the repository.

From the outset there should be an agreed approach to profiles vs permission sets. Given the challenges of deploying profiles; permission sets is definitely the way to go. But they need to be documented, managed and maintained. Think about your admin setting up a new user, how do they know what permission set/permission set groups to assign? - Minesh Patel, Solution Principal

Permission set groups are the new Profile

With profiles now essentially “empty” of configuration save for the items that cannot be controlled by Permission Sets, Permission Set Groups are now effectively representing the grouped permissions that would have previously been held in the profile. By creating Permission Sets (which by their nature are granular), these can be grouped together to form a Permission Set Group representing a business function. What this practically means is that the repository will contain an equal amount of non-administrator profiles and Permission Set Groups, and a higher number of Permission Sets that represent the access required by users of Salesforce. These individual Permission Sets are re-used across different Permission Set Groups (such as a Permission Set to access and edit Accounts, Contacts, and Opportunities being re-used by the “Salesperson” and “Data Manager” Permission Set Groups).

Automate permission set group assignment

With a 1:1 ratio of Profile to Permission Set Group, it is possible to use automation to automatically assign a Permission Set Group to a user when they have a corresponding Profile assigned to them. The following describes the series of steps you’d implement in a User object trigger handler class:

Determine if the change was to the ProfileId field

Get the name of the profile being replaced (Profile object, using the old Profile ID)

Get the name of the profile being assigned (Profile object, using the new Profile ID)

Unassign the permission set group matching the name of the profile being replaced (PermissionSetGroup and PermissionSetAssignment objects)

Assign the permission set group matching the name of the profile being assigned (PermissionSetGroup and PermissionSetAssignment objects)

The logic could become more or less complex depending on the needs of your organization but can be a powerful tool in ensuring permission consistency between environments.
['Aaron Allport']
['Technology', 'CRM', 'Salesforce', 'Release Management', 'DevOps']