Access to edit object records is controlled first at the object level by the user’s security profile and then (if configured) by Dynamic Access Control at the object record level.
Object field-level security provides another layer of control, allowing an organization to dictate which users can view or edit a specific field on an object record. Field-level security can be configured at two (2) levels.
- Profile Field-Level Security: Allows you to secure object fields by security profile through permission set assignments. Field security settings are independent of the object record states or a user’s assigned roles on object records.
- Atomic Security: Allows you to secure object fields by individual lifecycle states, with the ability to override settings, by state, for specific application roles.
Configuring Profile Field-Level Security on Objects
Access to edit object records is controlled first at the object level by the user’s security profile and then (if configured) by Dynamic Access Control at the object record level. Profile field-level security provides another layer of control, allowing an organization to dictate which users can view or edit a specific field on all records for a given object.
For example, the VeePharm eTMF Vault uses a CTMS integration to manage certain study and location data in an external system. The integration tool uses a Vault user account, called the “integration user,” to gain access to and update records. To ensure that Vault users cannot edit the data pulled in from the CTMS, VeePharm configures field-level security on certain fields within the Study, Study Country, Study Site, and Location objects. VeePharm grants only Read permission to most security profiles but grants Read and Edit permission to the integration user’s security profile. This creates a situation where most users can see but not edit those fields, but where the integration tool can still update the values. Field-level security utilizes users’ security profiles and attached permission sets to control access. Because standard security profiles are not editable, your Vault must use custom security profiles to use this feature.
Field-Level Permissions
When editing a permission set, Admins can grant the following permissions:
- Read: Allows a user to view the field label and value, but not edit the value. Without this permission, the user cannot see or use the field in any way, including filtering on an object tab or grouping in a report. The user may occasionally see the field name, for example, when trying to perform an action that uses a hidden field, but will never see the field value.
- Edit: Allows a user to edit the field value.
Note: Users must also have permissions at the object-level for Vault to enforce field-level permissions.
Accessing Field-Level Security Settings
You can view and edit field-level security from within a specific permission set: Admin > Users & Groups > Permission Sets. Navigate to the Objects tab and click into a specific object. In the Object tab permission grid, an asterisk appears on any permission with field-level security settings.
How to Set Field-Level Security
To set up field-level security settings:
- From the Permission Sets page, click into a permission set and open the Objects tab.
- Open a specific object by clicking the object label.
- Click Edit.
- Use the Read and Edit checkboxes to assign or remove permissions on each field. The permission must be on at the object level to be accessible at the field level.
- Click Save to make the changes effective.
Dynamic Access Control
You can use field-level security and atomic security with or without Dynamic Access Control (custom or matching sharing rules). If DAC grants Gladys read-only access to the WonderDrug product, but her security profile grants her edit access to all fields on the Product object, the DAC rule still prevents her from editing. If DAC grants Gladys edit access to the WonderDrug product, but her security profile grants her read-only access to some fields on the Product object, field-level security prevents her from editing the read-only fields.
Configuration Limits
Limits on Join Objects
Simple join objects (which support many-to-many relationships) do not allow field-level security configurations.
Limits on Standard Fields
In order to preserve functionality, we prevent certain field-level security changes for specific standard fields.
The following fields cannot be hidden, meaning that you cannot remove Read permission:
- ID
- name__v
- lifecycle__v
- state__v
- status__v
- object_type__v
The following fields cannot be editable:
- ID
- lifecycle__v
- state__v
Application Limits
Certain objects and fields are critical to the functioning of the Vault application. Vault will not allow you to add field-level security configurations to these. For example, you cannot set up field-level security on the Study, Study Country, and Study Site objects in eTMF.
Contact your Veeva representative for a full, current list of protected fields and objects based on your applications.
Audit Trail & Logs
When field-level security is set up to hide certain fields, Vault hides those fields in individual object record audit trails.
Copying Records
When users copy records (including hierarchical/deep copy), Vault ignores any field-level security that affects that user who initiated the copy action: hidden or read-only fields will still copy over to the new records.
Viewing Reports
Users cannot view reports that reference hidden fields in any way, for example, as columns or filters.
Related Sections in Page Layouts
You can use field-level security to create a security profile without Read permission on an object reference field, for example, the Product field on the Campaign object. Although the permission setting is on the Campaign object’s field, it hides the relationship between these two objects. If the page layouts for Product or Campaign include a related object list that utilizes this relationship, users with this security profile will not see that page section.