Permission Set Best Practice: Lets Get Functional

In almost any organization, an individual’s responsibilities may represent their job function, processes that they use or are part of, individual tasks they need to perform on a daily basis, the region in which they work, etc.  As the organization grows, and the user's responsibilities with it, the administration of profiles becomes harder as one-off profiles become common place.

With permission sets, a user’s total access is determined by both a their profile and their assigned permission sets.  This allows the administrator to focus on individual job functions, tasks, processes, etc., instead of trying to build the perfect profile for any given user.

Some organizations define their access requirements by making use of a simple matrix, for example team + process.  That is, different teams within an organization have different access requirements, but there are some processes that span all teams and various team members can participate in any number of these processes.

Even considering the simplest case where users are members of a single team and must participate in exactly one of these processes leads to 16 distinct profiles to manage, one for each cell in the above table.
Even considering the simplest case where users are members of a single team and must participate in exactly one of these processes leads to 16 distinct profiles to manage, one for each cell in the above table.

Permission sets can make this simpler.  We can define 8 permission sets (that’s half the number of profiles we would have had to manage in the simplest of cases) corresponding to each row and column in the above table, and can assign those permission sets out as appropriate to our users.  This also means any individual user may participate in more than one team and more than a single process, a capability that would have required a lot of profiles!

For example, consider an organization where the administrator has identified 10 different job functions or tasks that a user may be part of.  In theory, a user may participate in a single job function, or all 10.  That’s a lot of possible profiles; in math terms:

In practice, a lot of these possible combinations do not actually exist within an organization, but it is difficult for an administrator to know exactly which.  Permission sets have the potential to greatly simplify the administrator’s job while allowing for all 1,023 possible combinations with less work overall.

Applying the best practice from this section, the administrator need only define 10 separate permission sets, each encapsulating all the permissions and access settings required to perform one of the 10 job functions or tasks identified.  With permission sets, each user has exactly the set of permissions required in order to perform all the functions and tasks for which the user is responsible.

Log in as Any User Without First Having Access Granted

A year ago, we released an enhancement to the Grant Login-as screens that changed how long a user could grant access to an administrator or salesforce.com customer support representative. Instead of being able to set an expiration date sometime in the far away future, we began to limit it to no longer than one year of login access.

This had a significant impact on administrators and implementation consultants alike who use the login access feature to:

• troubleshoot user issues
• train users
• phase in new configurations

In the past, administrators and consultants would work around the fact that users had the right to grant and revoke access. In some cases, they would change a user's email to their own, reset the password, login as the user, and grant login access indefinitely. In other cases, administrators would just instruct their users during on-boarding to set grant login access as far in the future as possible. Finally, some would create videos and tutorials explaining to end-users how to grant login access. In any case, the process of granting access could be an obstruction for administrators who just wanted to help their users as quickly as possible.

Shortly after the release, I heard from some of our MVPs(Most Valued Players) about their difficulties trying to actively support their users.

What I learned from them is that login access is such a critical tool for administrators and consultants that providing the ability and security settings for an user to grant or revoke access was secondary to helping their users out when critical issues arise. In some situations, it is appropriate for these administrators and consultants to have login access regardless of whether their users granted it or not. In fact, because explaining the steps to grant login access could be such a time consuming exercise, administrators were resetting email addresses and passwords to do this for their users before any issue came up, which in itself is a security issue.

As a result, we developed a feature in the Summer '12 release that allows an organization to opt-in to the ability for organization administrators to login as any standard user without first having the user grant access. By having this feature enable in your organization, an administrator with Manage Users permission can then enable or disable it as it applies to them through the Login Access Policies page using an organization preference that they control.  When enabled, their end-users lose the ability to grant access and administrators can automatically login as them. When disabled, their end-users can once again choose whether to grant or revoke login access to their administrators.

From a segregation of duties perspective, users with Modify All Data or Delegated Administrators can login as other users, but because Manage Users permission is required to enable the organization preference on the Login Access Policies page, these login-as proxy users cannot control whether this policy applies to all users in the organization.

If you are interested in having this feature enabled in your organization, please contact salesforce.com customer support or your account team.

"Check All" Field Permissions in Permission Sets and Profile User Interfaces

I often hear from the admins that I talk with that the enhanced profile and permission set user interfaces *really* need the ability to check all field level permissions. In fact, I just heard it again from my friend, David Schach (@dschach), a couple days ago that he needed this exact kind of functionality. Especially where there can be 50, 100, or 800 custom fields for an object, you could sit around all day long checking checkboxes and cursing the interface.

There are ways to handle this programmatically or through a tool like the data loader or workbench where you can load fieldpermission (field level security) rows on permission sets and across objects very quickly. However, most admins will add field level security through the user interface and need a way to quickly enable *all* fields.

Someone posted the following blog by Keith Clarke on twitter: http://force201.wordpress.com/2011/10/17/check-all-in-permission-set-and-profile-ui/ which gives a great hack for handling this in the user interface. The workaround is to use a Google Chrome extension: https://chrome.google.com/webstore/detail/check-all/nnbihdpkeohjdfncchjhidbbonnihaob. I use chrome all the time and love this extension.

There is an idea to handle this natively in the profile and permission set user interface: http://success.salesforce.com/ideaView?id=08730000000k56ZAAQ. Until we get around to handling this, I definitely recommend either the chrome extension or using data loader to load field permission rows to permission sets.