Configuring 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.

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. 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.

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:

  1. From the Permission Sets page, click into a permission set and open the Objects tab.
  2. Open a specific object by clicking the object label.
  3. Click Edit.
  4. 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.
  5. 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

Invalid Object-Level Configurations

If your vault includes permission sets with Read and Create only (without Edit) permissions on any object, you cannot use field-level security. To fix this, make sure that any permission sets with these permissions also include Edit permission.

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.

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 treats individual object record audit trails differently from the audit histories in Admin > Logs.

  • Audit trail on an individual record: Audit entries related to a hidden field do not display.
  • Audit history in Logs tab: All audit entries are visible, even those related to fields that the viewer cannot see.

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.

You can use field-level security to create a security profile without Read permission on an object reference field to hide the relationship between two objects, including any related object page layout sections.