Where'd that field go? Installing permission sets with field permissions in group and professional edition.

I had a question come up the other day from Scott Hemmeter of Arrowpointe. Scott asked how managed permission sets with field permissions work when installing in a group or professional edition org. To simplify this post, I'm going to focus primarily on professional edition but much of this also applies to group edition as well.

Customizable profiles is automatically enabled in enterprise and unlimited edition orgs and is an add-on feature for professional edition orgs. If you have customizable profiles, you can create and edit profiles or permission sets, create more than one page layout per object, and create FLS (field level security also known as field permissions) in your org.

Unlike enterprise and unlimited edition where a user would need both FLS and the field exposed on the layout to see it on an individual record, the way a professional edition administrator controls access to a field is by adding it to the one page layout they are given for each object, at which time the field becomes available throughout the org.

However, there's nothing stopping a professional edition administrator from installing a managed package with permission sets that contain FLS. This has the potential to 'hide' fields from users who have this permission set assigned but do not have this field added to their page layout. As a result, a best practice for ISVs is to include all fields on their packaged page layouts to ensure that a user would see this field everywhere.

For example, lets assume a managed package has both a new field and a permission set granting read or read and edit FLS for that field.

Our first question should be, does the user have access to the field where access may be defined as:

• an end user using the API (application programming interface) to access the field values if API has been enabled in the professional edition org
• an end user using a list view to access the field values
• an end user using a report or dashboard to access the field values  
• an admin adding the fields back to the layout, even managed layouts that get installed from a package
• an admin adding a custom formula field to the layout that exposes the 'hidden' field values to the user
• a developer creating a Visualforce page exposing the hidden field values to the user

Graphic provided by Scott Hemmeter of Arrowpointe

The red shaded area represents the “hidden” field that professional edition users would not normally experience when they view a record using a page layout; however, they would still have access through other interfaces such as list views, reports, search, etc...

FLS on an installed permission sets is considered additive access for any user assigned the permission set – the only place where the field may appear 'hidden' in fact is the layout if the installed layout doesn't already have those fields exposed and even then the subscriber admin can always add the fields back to the layouts if they really want to.

So if you are an administrator in a professional edition org and you notice that there is a field that is not appearing on a record but a user says they can still see it in some other interface, there's a good chance there's a permission set assigned to the user and you should either remove the permission set assignment or add the field to the page layout so the user can see it everywhere.