Permission Set with Bare Minimum Profile - DevOps Lens

Salesforce is highly secure, robust and scalable SAAS platform which is why more and more enterprises are making it central to their system landscape and depend on it to smoothly run their business operation. Implementation and execution of DevOps practices is key to smoothly work on multiple projects in parallel while supporting business on day-to-day operation.

There are many great tools out there in market to support DevOps in Salesforce world, including GitHub, BitBucket, GitLab etc for version control. As of Winter '20 release, there are 130 types of Metadata that Salesforce has and there is no consistent behavior in all the metadata. Some of the metadata are very tricky to manage via Source Control and often cause challenges with deployment.

One of such metadata is Profile and managing it via Version Control often prove to be challenging based upon the complexity of org. Salesforce has acknowledged the challenge and it is very evident with their recent release of "Org Browser" for VS Code IDE with SFDX plug-in. Salesforce has not included Profile as one of metadata which you can pull from Org using "Org Browser" (if you have not explored "Org Browser" yet then you are missing on a very helpful feature).

Main challenge with profile is that, if you try to pull it via your IDE, it will only pull permissions related to components you have in your local project. If you have missed some metadata, like object, field, class etc then you will only have subset of actual profile and during merge with existing version you may loose existing permissions which will eventually impact your upcoming deployment. I have seen project teams maintaining profile permissions on excel sheet or some other way which has its own set of challenges.

I reached out to a few experts in Salesforce to know what recommendation do they have to manage profiles effectively via Version Control, and they officially acknowledged that they are aware of challenges and working to make it more manageable. They suggested, as a best practice to use Permission Set with bare minimum profile.

Profile with Permissions

To demonstrate it, I have created a profile "Custom: Sales Profile" which has user permissions on objects, fields and other required permissions, as shown below: -

I created a project using VS Code IDE & SFDX plug-in. I only pulled Account object and then pulled this profile. In this situation, metadata of profile only has reference to Account object and its fields. User permissions related to other objects are missing and if by mistake someone decide to deploy this profile using some CICD tool, it will go successful but eventually will fail the user test. I kept the use case very simple here intentionally to drive my point, in real world project there could be many more complication involved.

Profile with bare minimum Permissions and enriched Permission Set

I have created a profile "Custom: Sales Profile - Bare Minimum" and took away all the permission on all objects, as shown below: -

When I pulled this profile in my local project, I got something like this: -

As you can see there is no object permission in this profile which is intentional.

I have moved all the object permission to a permission set (just Account and Contact for our example): -

When I pulled this permission set in my project, it pulled permissions for both Account & Contact even though in my project I only have Account object included as shown below: -

The key is that, you can refresh a permission set from org without including related metadata which make it relatively easy and simple to maintain.

A downside is that you have to write some automation to assign a specific permission set (or a set of) when a user is assigned to a particular profile. This is not too bad, as Salesforce supports permission set assignment in process builder (point and click).

Please see below diagram as a reference to see what type of permissions you can and can't assign via permission sets.

Feel free to share your experience and happy to discuss it further. Happy DevOps!