FieldPermissions

Supported Calls

create(), delete(), describeSObjects(), query(), retrieve(), update(), upsert()

Special Access Rules

In API version 49.0 and later, only users with the View Setup and Configuration permission can access this object.

Fields

1Select SobjectType, Field From FieldPermissions where Field='Contact.Account'

1Select SobjectType, Field From FieldPermissions where Field='Contact.AccountId'

1Contact, Contact.AccountId

Usage

FieldPermissions work similarly to ObjectPermissions. However, FieldPermissions includes a Field attribute to return the name of the field.

For example, the following query returns all FieldPermissions records that have at least the “Read” permission. The results include the field, object, and permission set names.

1SELECT SobjectType, Field, PermissionsRead, Parent.Name
2FROM FieldPermissions
3WHERE PermissionsRead = True

Include the field’s parent object when querying FieldPermissions. For example, to find all rows that match the Account object’s Type field, create the following query:

1SELECT Id, SobjectType, Field
2FROM FieldPermissions
3WHERE Field = 'Account.Type' AND SobjectType = 'Account'

To find which permission sets are backed by profiles with the Account object, you can use a query like the following example:

1SELECT Id, ParentId, SobjectType, Field, PermissionsEdit, PermissionsRead, Parent.Name
2FROM FieldPermissions
3WHERE SobjectType = 'Account' and Parent.IsOwnedByProfile = true
4ORDER BY SObjectType, Field

Both SobjectType and Field must be included in the SELECT line of the query. Provide the full API name of the field in the form of SobjectType.Field when querying for a field.

Special Properties for Field Permissions

The auto-number and formula fields have special rules for how field permissions work. Both have FieldPermissions records, but inserting and updating is limited to PermissionsRead. PermissionsEdit isn’t allowed for either field type, since these fields must be read-only for users.

The following field types don’t return a FieldPermissions record because they are assumed to always be readable.

• Id
• CreatedById
• CreatedDate
• IsDeleted
• LastModifiedById
• LastModifiedDate
• SystemModStamp

The following field types don’t return a FieldPermissions record because they are assumed to always be readable and writable.

• OwnerId
• Master-detail custom (relationship) fields
• Universally required custom fields

As a result, the following query returns no records, even though users do have some access to some of the fields.

1SELECT Field, SobjectType, PermissionsRead
2FROM FieldPermissions
3WHERE Field='Id'

To determine if a field can return a FieldPermissions record, you can call a describeSObject() on the field. For example, describeSObject('Merchandise__c'), returns all the properties of the Merchandise custom object, including field properties. If you use a field whose permissionable property is false (like the field types listed in this section), you can’t query, insert, update, or delete field permissions records, because they don’t exist.

Working with Custom Activity Fields

While tasks and events are considered separate objects, they share a common set of activity custom fields. As a result, when a custom task field is created, a custom event field is also created, and vice versa. You can display the custom field on the event layout, task layout, or both event and task layouts.

Although custom activity fields are shared between tasks and events, you see separate FieldPermissions records for the task and event. However, changes made to one field permission record are automatically made to the other. For example, if you create a custom activity field, assign field permissions to it in a permission set, and run the following query, the query returns two records with the same permission value.

1SELECT Field, Id, ParentId, PermissionsEdit, PermissionsRead, SobjectType
2FROM FieldPermissions
3WHERE SobjectType = 'event' OR SobjectType ='task'

If you then update one of the records with another set of field permission values and run the query, the same permission values for both records are returned.

Nesting Field Permissions

1SELECT PermissionsEditReadonlyFields,
2(SELECT SobjectType, Field, PermissionsRead, PermissionsEdit
3FROM FieldPerms
4WHERE SobjectType = 'Merchandise__c')
5FROM PermissionSet
6WHERE PermissionsEditReadonlyFields = true

As a result, it’s possible to traverse the relationship between the PermissionSet and any child-related objects (in this case, FieldPermissions). You can do this from the PermissionSet object by using the child relationship (ObjectPerms, FieldPerms, and so on) or from the child object by referencing the PermissionSet with Parent.permission_set_attribute.

It’s important to consider when to use a conditional WHERE statement to restrict the result set. To query based on an attribute on the permission set object, nest the SOQL with the child relationship. However, to query based on an attribute on the child object, you must reference the permission set parent attribute in your query.

1SELECT PermissionsEditReadonlyFields,
2(SELECT SobjectType, Field, PermissionsRead, PermissionsEdit
3FROM FieldPerms
4WHERE SobjectType = 'Merchandise__c')
5FROM PermissionSet
6WHERE PermissionsEditReadonlyFields = true

1SELECT SobjectType, Field, PermissionsRead, PermissionsEdit, Parent.Name,
2   Parent.PermissionsEditReadonlyFields
3FROM FieldPermissions
4WHERE SObjectType='Merchandise__c'