A New Approach to Security Using Permission Sets
With the release of Permission Sets in Winter 12 Salesforce has allowed us as consultants and implementation partners to take an entirely new approach to how we setup user permissions. While heading down the home stretch of a project we were designing the permissions for all of the different users within the org. In the past when we would hear that there are going to be seven different lines of business using the system with "standard users" and "managers" within each line of business we would have immediately thought, ok, it's time to clone a bunch of profiles to handle their slight nuances and differences. Luckily for us, Permission Sets were being released at the same time that we were doing this phase of the project so we were able to take a completely different approach from the onset and in the end we were able to launch with only the use of two, yes two, custom profiles for every user in the system.
How Did We Get To Two Profiles
The first questions we started to ask was about record types and page layouts. These are the first questions we typically ask at this point because Permission Sets still don't control these settings so depending on the answers we hear we would decide if we need different profiles. In this case we had two different types of users that would need different record types associated to them. These two user types became the basis for our profile design. We designed one custom API User profile and one Standard User profile. The next questions that we asked were around Tab Settings and as it turned out we were able to lean on the visibility of objects to control tab settings meaning if you can see the object then you can see the tab, if you can't see the object then you can't see the tab - simple enough and well within the design we laid out above with the two profiles. Lastly we asked about the app selection picker and we found that everyone was able to see the same two custom apps so again there was nothing leading us away from our two profile design.
The Nitty Gritty
Our next step was to go through all the standard and custom objects and define what the Create, Read, Edit, Delete (CRUD) permissions would be at the least common denominator. This took a little bit of a different mind set since in the past you would typically design a profile with exactly the permissions that you want your users to have but in this case Permission Sets were going to take care of the additional permissions, what we needed was the lowest common permission across all the different user types. We came to a matrix where we had certain objects where the profile controlled everything because all users were always going to be the same and in other cases we had objects where the profile literally granted no access to the object.
Once we decided on the object level CRUD permissions we moved on to define what system permissions and application permissions each user would have at the lowest common level - for example, all users were able to Run Reports so we included that in the profile but not all users should be able to Manage Cases so this was included in a subsequent Permission Set.
The Permission Sets
Whenever we came to find out that there were permissions that some lines of business users or managers should be able to do we put those in Permission Sets. A good example of this is the Customer Care (support) group. Pre Permission Sets we would have needed two additional profiles, one for the customer care users and one for the managers. In our implementation these two profiles don't exist, these users share the same standard profile that we created for all users and then assigned Permission Sets to both the customer care users and the help desk managers.
New Approach = Streamlined Results
The approach of breaking these permissions into Permission Sets makes administering the permissions within the system a lot easier for the system admin who is inheriting the system. To recap we ended up with only two profiles (excluding system admin) that our customer is going to use. One is for the API User to handle the integration that we built (so really only one user which is a system user) and the other is the standard user profile that is going to be assigned to every single end user in the system - this makes it a lot easier to manage users. There are currently fourteen Permission Sets to handle all of the differences between all the end users in the system - these Permission Sets can be expanded upon very easily and if ever there comes a time when a few random users need a few random permissions the system admin can really easily just create a new Permission Set and assign it to these users.
We were really excited about the general availability of Permission Sets in Winter 12 since we have been working with them for a while in pilot. The timing of them becoming generally available was perfect for us as far as this particular client was concerned because we designed their permissions structure from the start with Permission Sets in mind.
If you have any questions about our methodology or want to chat about Permission Sets feel free to shoot me a tweet at www.twitter.com/justedelstein or comment on this post here on the blog or on our Facebook page.
