# Configuring Field-Level Security on Documents Document security is controlled by the user role's security settings (permissions) for the document's lifecycle state. However, there are times when additional security is required at the document field level. For example, many organizations need to prevent users from editing _Major Version_ and _Minor Version_ when initially creating a document. Field-level security allows Admins to set fields as read-only, hidden, or editable for specific users or groups. Each field also has a default security level of editable, read-only, or hidden that applies user for which there is no override. Field-level security can only further restrict security applied at the document level by the security matrix. It cannot give a user more permissions on a field that they would otherwise get via document security. Field-level security is treated like any other security setting and is respected by the Vault API. ## Types of Field-Level Security * **Editable**: The field is visible and editable by all users with the **Edit Fields** permission. This is the default field level security setting. * **Read Only**: The field is displayed in read-only mode for all affected users and groups, regardless of whether the document itself is editable by the user. The only time this security level is exposed to the user is when they are editing a document and certain fields stay Read Only. * **Hidden**: The field is not available to affected users and groups. It does not appear on the Doc Info page in either view or edit mode, in the faceted navigation controls on the left side of the library page. Its field values are not searchable by the user, and it cannot be queried via the Vault API. When thinking about the information architecture of Vault, consider how permissions-based document security interacts with field level security. Document security varies by lifecycle state and is associated with roles, which can be filled by different users on different documents. Field-level security maps to specific users and groups and does not vary based on the document's lifecycle state. Field-level security is useful for rules that apply at all times. For example, no users in a department should ever be able to update a certain set of fields. ### Hidden Fields in 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. ## Accessing Field-Level Security Settings You can view the security settings for a document field from **Admin > Configuration > Document Fields > [Field Label] > Security Overrides**. Only Admins with the _Document Fields: Edit_ permission can modify these settings. ## About Default Security The **Default Security** setting applies to any users who do not have a security override. Each field's default security is automatically set to _Editable_. You can restrict this if, for example, you want only a few users or groups to have edit permissions on a field, and everyone else should be read-only. In this example, set the default setting to _Read-Only_ and create overrides for specific users with the _Editable_ setting. ## About User and Group Overrides To exempt a user or group of users from the **Default Security** setting, you can create overrides for them. If a user is in a group specified in an override and also listed individually, Vault evaluates that user's security to the least restrictive setting. For example, Bruce Ashton has the setting _Editable_ and belongs to the group Viewers with the setting _Hidden_. Bruce Ashton's setting will be _Editable_.
## How to Set Field-Level Security To set up user and group security overrides: 1. From the **Security Overrides** tab, click **Edit**. 2. In the **Default Security** picklist, select a security setting. 3. In the overrides area, select a user or group and the security setting. 4. Add additional overrides by clicking the **+** icon. 5. Remove overrides by clicking the _-_ icon. 6. Click **Save** when done editing. ## Viewing Which Fields Have Security Overrides The list on the **Document Fields** page shows an icon to indicate the fields with security overrides. Click the icon to go directly to the **Security Override** tab on the appropriate field page. Field Security Override Icon ## Viewing Which Users Have Security Overrides You can see if security overrides are assigned to a specific user through the user detail page. This page has a **Security Overrides** tab which displays all overrides that apply to the user, either directly or through a group membership. ## Controlling Initial Version Numbers By default, a document's initial version number is editable to better support document migrations. However, allowing users to modify the _Minor Version Number_ and _Major Version Number_ fields on new documents that they create can cause version tracking and auditing issues for some organizations. You can prevent this by making the field read-only. To ensure that the initial version is always 0.1, set the **Default Security** setting on _Major Version Number_ to **Read-Only**. _Major Version Number_ and _Minor Version Number_ are linked, so any security changes that you apply to one of these fields will automatically affect the other. When you create or update documents in Document Migration Mode, Vault will always allow editing of the version number for any documents created using bulk processes through the Vault API.