Profiles are the foundation of any Database.com or Force.com security policy implementation. With the Winter ’12 release, permission sets now complement profiles, letting you more efficiently implement and manage your organization’s security policy. Read on for a quick primer on perm sets.

A Quick Review of Access Controls

The profile that you assign to a user controls basic things like when the user can log in, from where, and among other things, which database objects and fields a user can access. After that, object-specific features such as organization-wide record sharing models, role hierarchies, groups, and sharing rules determine how to share records that a user owns. If you need a refresher on these concepts and features, please read Understanding Database.com System and Data Access Controls.

Profiles, As They Were

Before the Winter ’12 release, a profile is the only feature you can use to control which database objects and fields that a profile user can access. Consequently, this leads to two unfortunate situations.

  • When your organization has two very similar types of users that vary by even a single object or field permission, you need to create two different profiles to satisfy your requirement. Multiply this by five, ten, or more times, and you get what many administrators commonly refer to as “profile explosion.”
  • As the complexity of your organization schema grows with more and more objects and Apex classes, each profile typically becomes unwieldy as it must account for an overwhelming number of permissions.


Permission Sets to the Rescue

With Winter ’12, permission sets let you implement and manage security policies much more efficiently than ever before. Here’s how it works.

  1. You create a base level profile for each general type of user (administrator, app user, etc.), and for each profile, assign base level permissions that are common to all variations of the corresponding user type.
  2. Create permission sets to handle exceptions to the base level permissions available via profiles.
  3. Assign a user a profile and the permission sets that, together, provide the user with the permissions necessary to perform their job.

Here’s another way to think about the relationship between profiles and permission sets. As you create multiple apps, it becomes easier to manage additional permissions (beyond what a profile controls) when you think about permission groupings by app rather than by user. Permission sets let you implement this type of association. For example, you might have base user profile along with the PTO manager permission set to approve PTO requests.

 

For a more information about permission sets, take a look at the recording of the popular Dreamforce 2011 session I Love Permission Sets: A Deep Dive Into Profiles 2.0.

Enjoy!

[Cross-posted at Database.com]

tagged Bookmark the permalink. Trackbacks are closed, but you can post a comment.