I have a new client with a crazy mess of permission sets and profiles. It looks like some other consultant converted all their previous profiles straight into permission sets and we now have about 150 permission sets named after various roles in the company, with no documentation of course. Any suggestions on how to start sorting this out?
- Sys Admins - do people generally have a single permission set for Admins that has R/W access to all fields/objects rather than relying on the profile? Now that the field creation flow shows permission sets, we have lots of fields that are not available to system admins as it was not added to the admin profile.
- Role based vs functionality or object based - any thoughts on having perm sets around each object (view only vs standard user edit vs special edit scenarios) or by functionality (quotes and opps together for a 'Quoting' permission, other objects grouped for 'Account Mgmt' and 'Customer Service' etc)?
- Any recommended tools you have used to document or discover what is in each of the existing permission sets to evaluate if we keep them, or perhaps we just start fresh and eventually retire all the existing perm sets?
Thanks for any advice or experience you can share
@User Access & Permissions Assistant @The Future of User Management @Architect TrailblazersThanks everyone for chiming in, this is a great discussion. @Mike Megliola I have used PermComparator before and it's pretty good at highlighting differences but still doesn't show all the nuances of what you can have on a profile (record types, page assignments etc). I'm going to check out Jetstream and I think I will likely ignore most of what the client has today and start fresh. The existing permission sets are mostly just profiles that were auto converted into perm sets and have a lot of conflicting information, like FLS on objects that they don't have CRUD for etc.
