# 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 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.
* **<a href="/en/gr/47850/">Atomic Security</a>
**: 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.

<div class="note-border alert-info">
  <div class="alert alert-info" role="alert">
    <div><i class="far fa-info-circle"></i></div>
    <div class="alert-text">
      <p><strong>Note</strong>: Users must also have permissions at the object-level for Vault to enforce field-level permissions.</p>
    </div>
  </div>
</div>



## 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 {#config-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 <a href="/en/gr/517/#object-record">individual object record audit trails</a>
.

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

## Hidden Fields on Reports & Dashboards {#hidden-fields}

When a field is hidden from a user using field-level security and they view a report that contains a column for the hidden field, the column is hidden from the report, and the user cannot edit the report. If the hidden field is used in report logic, such as grouping, formula fields, or conditional fields, an error is displayed when the user attempts to view the report.

When a field is hidden from a user using field-level security and they view a dashboard component that references the hidden field, the field is hidden from the component. The user cannot edit dashboard table charts that contain a column for the hidden field. If the component references a report with a hidden field used in report logic, such as grouping, formula fields, or conditional fields, an error is displayed for the dashboard component.

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