Permission sets represent a fundamental shift in enabling a user's access. As a result, you should have a release strategy before rolling out new permission sets to users in your org.
As with other important changes made to an org, you should first create permission sets within a Sandbox environment and test them with actual users. This will enable you to effectively test a user's access prior to rolling it out to production but it will also give you an opportunity to discuss with other Admins the use cases which will make sense for your deployment. And because permission sets are supported in Change Sets, it's easy to move them from sandbox to production.
Instead of fixing existing profiles and their clones, consider preventing one-off profiles being created from this point forward as a good first step in phasing in permission sets.
If you do choose to remove permissions from your profiles and migrate them to your permission sets, consider doing the following:
- For any group of users, select/ask for 3-5 ‘volunteers’ to participate in a control group. Make sure they have the time and willingness to give you feedback, and allot time for yourself to make corrections as they use the app.
- Do not delete existing profile.
- Create a baseline profile that represents all of the layout, field permissions, and other configurations necessary for this small group to get their job done. Keep in mind that this profile should be designed as a resuable set of baseline configurations (will be usable by more than this control group’s functional role).
- Create the additional permission sets consisting of user and object perms necessary for them to do their job.
- Add on other control groups to the profile, differentiating the users by the permissions in their specific permission sets.
As an example, you may have created a one-off profile in the past that represents all users who have read access to the app but a couple of additional permissions that make them different like the ability to single sign-on or use the API. Design a profile that removes these different permissions but establishes a baseline set of field permissions, layout assignments, etc that is a simple user. For these users, add the permission sets that set them apart from this baseline profile including the necessary read permissions on objects. As other groups need to have some read access to the app, create different permission sets that represent that grouping but assign them the same profile that is shared by the original control group.
As with other org changes, implementing permission sets in phases using sandbox deployments and isolated use cases is the best practice for managing changes in a user's access rights.
