Salesforce: Query Fields Permission

In the previous blog Using Permission Set to Query User Permission, we discussed query on PermissionSet and PermissionSetAssignment to query on permissions related to the user permission, at the end of the blog we also introduce query to ObjectPermissions object to get permission related to Object.

In this blog, we are going to introduce another object called FieldPermission. As you know, basic field accessibility for a user is determined by the user Profile, then extra permission can be given to the user through Permission Set. So, a query to FieldPermission will give you an idea of why/how a user able to access a specific field, and what is the permission to that field (Read or Edit).

SELECT Id, ParentId, Parent.Name, SobjectType, Field, PermissionsEdit, PermissionsRead
FROM FieldPermissions
WHERE SobjectType = 'Account' AND Field = 'Account.Active__c'
ORDER BY Parent.Name

The sample result from the above query:

The main field from the above query is ParentId, this field is referred to PermissionSet object, so you see the result of Parent.Name is PermissionSet.Name, the values are contained for both Profile and Permission Set.

For PermissionSet.Name value starts with X00e, it is a Profile (includes Standard and Custom profile), while the one not starting with X00e is PermissionSet.

From the above screenshot, let us check if Activate_Contract_2 permission set gives extra permission for the field Active__c in the Account object:

Sample 2: the below query checks the extra permissions given by the permission set to read and edit fields by a permission set called 'Activate Contract 2' and if the perm set also gives permission to edit read-only fields. 

SELECT SobjectType, Field, PermissionsRead, PermissionsEdit, ParentId, Parent.PermissionsEditReadonlyFields

FROM FieldPermissions

WHERE Parent.IsCustom=True and Parent.Name = 'Activate_Contract_2' ORDER BY Field 

Here are the read/edit permissions setting for the Account object in that perm set.  

The parent here object is PermissionSet, and the child object is the FieldPermission. 

IsCustom in PermissionSet means, if true, the permission set is custom (created by an admin); if false, the permission set is standard and related to a specific permission set license.

Sample 3: now we query the child from the parent object, this query shows the permission set or profile that gives allows to edit read-only fields and shows all fields access in the Account object

SELECT Id,Name,PermissionsEditReadonlyFields, IsOwnedByProfile, 

  (SELECT SobjectType, Field, PermissionsRead, PermissionsEdit

   FROM FieldPerms

   WHERE SobjectType = 'Account')

FROM PermissionSet

WHERE PermissionsEditReadonlyFields = true

Reference: 

• FieldPermissions
• PermissionSet

Salesforce: easier way to see what is inside a Permission Set

When you enable a permission using permission set or profile, Salesforce will automatically enable other permissions needed to enable that permission. Salesforce will tell you what permissions will be enabled when you enable a permission, however, it will not tell you other permissions will be enabled by enabling the required permissions. Imagine this, to enable permission A, the system will tell you that it will enable permission B as well, however, to enable permission B, it needs to enable permission C and D, so you are not aware that C and D actually enabled by a Permission Set.

For this example, I create a permission set to enable a permission called "Activate Contracts".

From the above screenshot, you aware that, by enabling Activate Contracts, it will enable Edit Order and Edit Contract, and not more than that. But, let's check with Setup Audit Trail.

Let us see each line from the above audit trail screenshot:
5th - create the permission set
4th - enable read and edit for Contract object, this makes sense that to edit, the user needs to read
3rd - enable read for Account object, this is because Contract record accessibility depends on Account.
2nd - enable read and edit for Order object, this makes sense that to edit, the user needs to read
1st - enable the permission set

Because the permission set is just created, we can monitor it from the audit trail, but for the existing permission sets, you can't find the history after 6 months. So, you need to open each tab in the permission set - that's not ideal :(

Also for the scenario where you have many admins and the documentation practice is not strong, some admin adding permissions without other admin awareness, so you have no visibility of what is inside the permission set.

Is there an easy way to tell what is "inside" a permission set?
Yes, as Salesforce awesome admin, you are supposed to fill in the "Description", this will help yourself in the future, or your successor. However, Description only can have maximum 255 characters.


Check with Metadata
Because of all extra permissions in the permission set are written as metadata, you can download the permission set metadata and "see" all permissions enabled for the permission set with a simple text editor.

Salesforce inspector comes to help, it is pretty handy and nothing needs to be installed to your Salesforce org., just follow the step to download permission set metadata into a zip file.

Salesforce inspector panel

select permissionsets and click Download metadata

wait for a few seconds to download the metadata

Extract the zip file, each permission set will be stored as a file with the extension ".permissionset". Open the file with a text editor, such as Notepad++, now you have full visibility the content of that permission set, it will tell field permission, object permission, custom permission, apex class, tab setting, apex page, user permission. etc.

<?xml version="1.0" encoding="UTF-8"?>
<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
    <fieldPermissions>
        <editable>true</editable>
        <field>Account.Acc_Percent__c</field>
        <readable>true</readable>
    </fieldPermissions>
    <fieldPermissions>
        <editable>false</editable>
        <field>Account.Active__c</field>
        <readable>true</readable>
    </fieldPermissions>
    <hasActivationRequired>false</hasActivationRequired>
    <label>Activate Contract 2</label>
    <objectPermissions>
        <allowCreate>false</allowCreate>
        <allowDelete>false</allowDelete>
        <allowEdit>false</allowEdit>
        <allowRead>true</allowRead>
        <modifyAllRecords>false</modifyAllRecords>
        <object>Account</object>
        <viewAllRecords>false</viewAllRecords>
    </objectPermissions>
    <objectPermissions>
        <allowCreate>false</allowCreate>
        <allowDelete>false</allowDelete>
        <allowEdit>true</allowEdit>
        <allowRead>true</allowRead>
        <modifyAllRecords>false</modifyAllRecords>
        <object>Contract</object>
        <viewAllRecords>false</viewAllRecords>
    </objectPermissions>
    <objectPermissions>
        <allowCreate>false</allowCreate>
        <allowDelete>false</allowDelete>
        <allowEdit>true</allowEdit>
        <allowRead>true</allowRead>
        <modifyAllRecords>false</modifyAllRecords>
        <object>Order</object>
        <viewAllRecords>false</viewAllRecords>
    </objectPermissions>
    <userPermissions>
        <enabled>true</enabled>
        <name>ActivateContract</name>
    </userPermissions>
</PermissionSet>


PermComparator
Another option is to use PermComparator, however you need to switch between User Permissions, Object Permissions, and Setup Entity Permissions to see all extra permissions added in the permission set.

However, from my experience, PermComparator does not list all permissions, probably it has not been updated for a while, example: Allow View Knowledge, Subscribe to Reports.

Enable Record Type with Permission Set

Back to the basic series - permission set for the record type access.

I had a discussion with a user group member, which is subject matter expert (Salesforce biz owner) in his company. He is using Record Type to differentiate Account Type, where the different type of Account has the different layout. This is a good usage of the record type. But, he also complains his workload because of a special record type that only able create by him as the biz owner, salespeople are not allowed to create this special type of Account, but only able to see.

He would like to give the ability to a sales support user ability to create that special Account type, let's call it "Not-normal" for this blog. But, he also not able to make that sales support user have the same Profile as him.

Solution: use Permission Set
Create a new permission set and assign it to that Sales support.
When you are in the Permission Set, select Object Settings, for the object (in this case is Accounts), you will see Account: Record Type Assignments and enable Not-normal record type.

Then assign the permission set to that sales support user, I'll not discuss how to assign the permission set in this blog, but you just need to click "Manage Assignments" button.

Salesforce: Edit Converted Leads

If you have used Salesforce for a quite long time, you may aware that once a Lead is converted, you will not able to view the lead detail, except with report, and will not able edit it, even using API.

But, since Spring '16 Release, a user with special permission will be able to view and even edit the converted lead, directly in Salesforce page. This is a good move, in many cases Sales Ops or super user needs to edit some details in the converted lead.

In the previous blog Set Audit Fields upon Record Creation, we discussed a new permission for user able to populate Create Date, Create By, etc., but a user with the same permission "Set Audit Fields upon Record Creation" will be able to edit a converted lead too.

Thanks to Daniel Peter for pointing a new permission "View and Edit Converted Leads" introduced in Spring '17 Release, this permission reduces "Set Audit Fields upon Record Creation" permission just for the purpose of set audit fields on the record creation. I personally see this is a great approach in separating the permissions, because of the different usage.

Let's see a converted Lead in Classic, even we manually type in the URL, example: https://ap2.salesforce.com/00Q28000002fPqZ, it will be auto redirect to https://ap2.salesforce.com/p/lead/ViewConvertedLead/d?id=00Q28000002fPqZ

But, let's see when a user with "Set Audit Fields upon Record Creation" permission opens the same lead:

This user, able to see and even edit the record from Salesforce page.


Now, let's see what will be happened in Lightning for the same users. For the 1st user without Set Audit Fields upon Record Creation permission, the page will be auto redirect to the converted Contact.

While for the 2nd user with Set Audit Fields upon Record Creation permission, it will stay at the Lead page, so user able to view, and even edit the converted lead.

Editing converted Lead:

Reference:

• Leads: Update Details for Converted Leads in Salesforce Classic
• Let Marketing and Sales Ops Users View Converted Leads

Salesforce: Set Audit Fields upon Record Creation

More than 3 years ago, I wrote a blog Load Created By, Created Date, Last Modified By, and Last Modified Date (Audit Fields) on how to upload system fields, such as: Created By, Created Date, Last Modified By, and Last Modified Date in Salesforce. Usually, we need to do this as part of the data migration activity, where those fields are also known as Audit Fields in Salesforce.

Since Winter '16, Salesforce introduces a permission called Set Audit Fields upon Record Creation. By default, a standard profile will not have this permission enabled, such as for System Administrator profile, so you have to create a Permission Set with that permission, then assign the users with that Permission Set.

But, if you do not see this permission, navigate to Setup | Customize | User Interface, and look for a checkbox Enable "Set Audit Fields upon Record Creation" and "Update Records with Inactive Owners" User Permissions", make sure this checkbox is checked.
If you untick this option, the permissions will be disappeared, even it is selected in Permission Set and has been assigned to users.

Once you assigned with "Set Audit Fields upon Record Creation" permission, you should see audit fields like CreatedById, CreatedDate in API tools, such as: Data Loader, Workbench, etc.


This is before have "Set Audit Fields upon Record Creation" permission.

This is after have "Set Audit Fields upon Record Creation" permission.

Reference

• Considerations before having Create Audit Fields enabled