Salesforce

Salesforce Best Practices: Where Permission Sets Shine

Where-Permission-Sets-Shine-e1343380436935
salesforce permissionsA few months ago, I read a blog on permission sets and how another consulting company (Arkus) had managed to do an implementation with just two profiles. That same company has now created a tool called The Permissioner to mass assign users a permission set, which I think is a great help to system administrators who, like Arkus, are planning to heavily use permission sets.

I think Arkus has an interesting approach, and I agree that permission sets do limit (to a certain degree) the number of profiles you need.  However, I still find that profiles remain at the core of the Salesforce application and cannot imagine doing an implementation for one of our customers with only two profiles. Profiles are extremely robust and allow you to control many features that permission sets do not control. You set access to Tabs, Apps, and record types at the profile level, not on permission sets. Page layout assignments are done at the profile level. In reality, the profile should be at the core of what you are doing.  Then from there you can use permission sets to extend special permissions to users.

Where you really have to struggle with permission sets is when you try to use them to add full access to an object and take profiles out of the equation.  Adding CRUD permissions is easy through a permission set, but controlling full field-level security is more difficult. For example, imagine you were building out a new application and wanted only a few of your standard users to use the application.  The approach is not to create a permission set that gives full access to the objects and fields.  Instead, you’d want to control field-level security through the profile and CRUD permissions through a permission set that you would assign to users who will need to use the application. Why? If you try to control field-level security exclusively through a permission set, there are a lot of clicks involved (all fields are unselected by default and you have to manually click each and every field to add them to the permission set).

In addition, down the line, when you add a new field to an object, the application doesn’t allow you to select visibility for permission sets.  This is because you should be managing field-level security primarily off of profiles, and you would have to go find all permission sets affected by this new field and add visibility there. Always make the primary place you control field-level security on the profile, and if all users don’t need access to the object, grant access to it by permission sets. If you need to add more visibility or the ability to edit certain fields, add only those fields to the permission set.

I recently completed a project where we wanted to extend the Manage Public List Views permissions to a small set of users as well as delete permissions to a certain set of objects for managers of the application. Since page layouts, record types, and tab and application access were the same for managers and their direct reports, rather than creating a new profile we made a very simple permission set to manage list views permissions and delete permissions to several key objects. If there is a field that only managers should be able to access, make it read-only for the profile and give read-edit permissions to managers through the permission set rather than controlling editing through the page layout itself (which would mandate two page layouts). This is a great use of permission sets and a clear illustration of where they really shine.

Thoughts on “Salesforce Best Practices: Where Permission Sets Shine”

  1. Great blog posting! There are some excellent points made here. To address the number of clicks it takes to enable field permissions, check out the following blog posting: http://force201.wordpress.com/2011/10/17/check-all-in-permission-set-and-profile-ui/ for a great tool tip.

    We try to make it easier to enable field permissions on profiles because in simpler implementations, the default behavior is typically to give more access than less. But as implementations grow, we find the opposite to be true. More complexity often requires more control over access (i.e. assigning least privilege) which is easier to start when you have no access to controls like field permissions and less options to ‘select all’ which is often times selected out of default rather than an explicit desire to give everyone access.

    Hopefully you’ll continue to find new ways of using permission sets as we continue to add to the feature set. In the meantime, thanks for the feedback and excellent references in your blog posting!

  2. Hi,

    Actually i created fields using visualforce page but created fileds Field-Level Security for Profile(Administrator) place visible and editable checkboxes not checked(any profile not checked i am a administrator).Every time i will goto Setup->Manage->users>administrator->custom field level security->related object name and click view and checked to metadata created fields visible and editable.How to check this visible and editable checkboxes Using apex DML permissionsets dynamically through Coding?.

    please help me………

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to the Weekly Blog Digest:

Sign Up
Categories
Follow Us
TwitterLinkedinFacebookYoutubeInstagram