I keep thinking back to Permission Sets often, as I see very few teams adapt it in a true sense. Most seem to make a clone a Profile into a Permission set and that seems to be the end of it. With such an approach we miss out on the benefits and transparency that we could get with Permission Sets.
I was reading this recent blog post at Salesforce Architects blog, which touched upon package-based development. This product-based development mindset is an ideal use case where permission set fits in.
What is packaging mindset?
Look at the permission set based licenses that come with a lot of packaged apps that you install from Appexchange and you will have an idea. You could also look at a product like CRM Analytics (Formerly Einstein Analytics) and its permission sets. It has one for internal users, one specifically for people who need admin permission in CRM Analytics and a separate one if the person viewing the analytics is viewing it on an Experience site (community).
If the same had to be adapted to a regular Salesforce org, we could break apart some of the key functionalities that exist in an org and create permission sets for the same.
Are there separate teams that work on B2B and B2C leads in your company? Great put all the technical bits required for them to work on their leads into a permission set. Do some of them need functionalities related to campaign module? That goes into a separate Permission set.
The key is to identify key functionalities that can be broken down into Permission set without being too granular and unmanageable. This is where we need to apply the product-based thinking that we see in a lot of Appexchange apps. Or in other terms, treat these permission set as a free license you’re granting an employee to access a specific functionality.
Practical application: Dynamic roles
What if the same mindset had to be adapted to a sales team? In a very typical sales team we might have different profiles for
- Pre-sales team
- Sales Manager
- Sales Executive
- Other Sales Aligned Roles
In such a scenario, there is overlap in functions that are performed, but there are separate tasks performed by each and represented with different KPIs.
| Role | Permissions |
| Pre-sales team | 1. Work through lead 2. View own leads 3. Convert lead |
| Marketing user | 1. View all leads 2. Add a lead to a marketing campaign |
| Sales Manager | 1. View all leads 2. Work through leads 3. Convert lead 4. Create and manage opportunities 5. View team’s opportunities 6. Create and manage quotes 7. Sales Approvals |
| Sales Executive | 1. View own leads 2. Work through leads 3. Convert lead 4. Create and manage opportunities 5. View own opportunities 6. Create and manage quotes |
| Sales Engineer | 1. View opportunities 2. View quotes |
This table above works well if all the team members allocated to these roles do just these functions. However in a lot of companies there are always a few whose job overlap multiple roles, either entirely or partially. There are also people who need to perform additional responsibilities while they cover for a colleague on a break.
In such scenarios, the business requirement would be to “Provide X Sales Engineer all the permissions of Y Sales Executive for a week”. This could be addressed by changing the profile. What if the requirement was slightly more complex than that? What if it was, “Provide X Sales Engineer permission to create and manage opportunities for 10 days; all the permissions that Y Sales Executive has on the opportunity”.
While that makes for a simple requirement from a business point of view, the profile-based set up makes it time consuming to allocate to the new user and validate. This is the scenario I see often and the response to this is to create a new permission set with opportunity access and the field level permissions are painstakingly mapped out on to this permission set by an admin or a support team member and then assigned to the Sales Engineer.
Now what if this requirement could be mapped into a Permission set world? We could create permission sets based on functionality rather than basing it on the role itself. For this we need to think of each module as a group of functionalities that can be packaged or separated as required.
So for example, managing and converting lead could a permission set, while creating and managing opportunities could be another. Managing existing opportunities and creating quotes against could be another and so on. With these three permission sets we could broadly cover the multiple roles and the permutations and combinations that come up.
The table above could look like this
| Permission Set | Permissions |
| Create and manage own leads | 1. Work through lead 2. View own leads 3. Convert lead |
| Create and manage all leads | 1. Work through lead 2. View all leads 3. Convert lead |
| Marketing user | 1. View all leads 2. Add a lead to a marketing campaign |
| Manage opportunities | 1. Create and manage opportunities 2. View own opportunities 3. Create and manage quotes |
| Sales Approvals | 1. View all opportunities 2. Sales approvals |
| Limited opportunity access | 1. View opportunities 2. View quotes |
In such a scenario, we could assign “Manage own opportunities” permission set to the Sales engineer and the requirement would be met without the need for extensive testing to validate the permissions.
As a result the assignment could look like this
| Role | Permission Sets Assigned |
| Pre-sales team | 1. Create and manage own leads |
| Marketing user | 1. Marketing user |
| Sales Manager | 1. Create and manage all leads 2. Manage opportunities 3. Sales Approvals |
| Sales Executive | 1. Create and manage all leads 2. Manage opportunities |
| Sales Engineer | 1. Limited opportunity access 2. Manage opportunities (Optional) |
Practical application: Rapidly evolving process
Imagine a Salesforce org linked to an Experience Site (Community) through which the business wants to provide new functionalities every fortnight or month.
A product development mindset would be to release these functionalities as new package of functionalities in every release. Each package would have one permission set covering multiple functions or a separate one for each functionality, along with Custom permissions they require to work.
With this approach, the team will have the flexibility to pilot the functionality with a limited audience before it is released to the wider audience. The team would also be able to quickly roll-back any changes by removing one permission set as opposed to reverting multiple profiles on the site.
The only consideration would be to keep the permission set names relevant for business users (‘Raise a payment dispute’ for example) and not development driven (‘Sprint X’ for example).
Challenge
In the scenario above we are creating Permission Sets based on the known set of job functions that teams perform. Unfortunately in many companies the job functions are not as well defined or they change often with changing managers or organisational goals. In essence, such an approach will not work in environments where the job functions are not well defined.
The other challenge with permission set is at arriving at the right atomic level to base it on. In complex orgs, the teams might be compelled to create a separate permission set for each record type of an object or even for specific fields. These are realistic scenarios and there will be times when you too will be adopt this approach, despite the complexity.
Just like with development, over-optimising Permission sets to a granular level at an early stage can add huge overheads, as admins will then be left to deal with 100s of permission sets leading to its own fatigue and documentation challenges. The only way this can work is if Permission sets are named and described in a way that makes sense for business and not in a way that makes sense for the technical/implementation team alone. There is no way around periodic review of these permission sets and purging those that are no longer needed.
What do you think?
#1 Jay pointed out another challenge in terms of Lightning Page Layout assignments, which is still dependent on profiles. The only way around this would be to have separate apps and not assign it based on profiles.
#2 Ashish and Nikhil both pointed out the absence of Permission Set Groups and it is a very important piece of the puzzle. It lets you group permission sets together into a mock profile and even lets you create timed access. I’ll definitely extend on it further in a later post.
What do you think? Leave a Reply