# About the User & Person Objects

This article explains the _User_ and _Person_ objects. Managing users with the flexibility of Vault objects allows you to create reports based on user data, create custom fields, and reference users directly from documents with lookup fields.



<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>: The <em>User</em> object is provisioned with multiple <a href="/en/gr/953/#System_Owned_Users">system-owned user records</a>
 that appear in all Vaults. These accounts are used to capture actions that are performed by Vault instead of by a user. Although these records are visible when viewing and exporting the <em>User</em> record list, the records are not included in license counts, are read-only, and cannot be referenced by another <em>User</em> or document. The <em>System</em> user record is inactive, is not synchronized with Legacy Users, and does not appear in the <em>Users &amp; Groups</em> tab.</p>
    </div>
  </div>
</div>



## About the User Object

You can create and manage users with _User_ object records. The _User_ object contains a record for each existing member of your Vault. Additionally, if a user is a member of multiple Vaults, the user will have a record in each of the Vaults to which they have membership.

In addition, the _User_ object contains the _Standard User Detail Page Layout_, which organizes the _User_ object record layouts into <a href="/en/gr/26387/#pages">pages</a>
 and <a href="/en/gr/51632/">layout rules</a>
. You can use the  <a href="/en/gr/26387/#save-as-layout">_Save As_</a>
 function to make a copy of the _Standard User Detail Page Layout_ and modify it as needed.

### Creating User Records

Starting in the 20R1 release, Admins create all users with _User_ object records. You can access the _User_ object list page from the <a href="/en/gr/953/">**Admin > Users & Groups > Vault Users**</a>
 page. You can also access _User_ records from a custom _User_ object tab or **Business Admin > Objects > Users**, if available. When creating a new _User_ record, you can add a user from the domain to the current Vault, including <a href="/en/gr/38996/">cross-domain users</a>
, or create a new user.

The _User_ object page layout is the same across all _User_ object pages and the **Admin > Users & Groups > Vault Users** page. If you edit the _User_ object page layout, the changes apply to the **Admin > Users & Groups > Vault Users** page as well as all _User_ object pages.

## About the Person Object

The _Person_ object allows you to add individuals who aren't domain users to your Vault. This is useful for keeping records of individuals outside of your organization, such as contractors, that you may have worked with, but who aren't users in your Vault.

You can also reference existing users from a _Person_ record. This allows you to maintain user and non-user records within a single object.

### Creating & Updating Person Records {#create-persons}

To create _Person_ records, navigate to **Business Admin > Objects > Persons** and click **Create**. If you select a **User**, Vault populates the _First_ _Name_, _Last_ _Name_, _User Name_, _Language_, _Locale_, _Timezone_, _Email_, _Mobile_, _Image_, and _Manager_ fields with data from the referenced user when you save. This creates an outbound reference to the _User_ object. Vault syncs any changes to shared fields between both object records only if the shared fields are <a href="/en/gr/32857/#assign">assigned</a>
 to each _Person_ object type. Otherwise, the sync operation fails to execute. For example, if an Admin updates Dave's _Email_ on his _Person_ record, Vault updates the _Email_ field on his _User_ record to match and vice versa. If the _Email_ field is not available on all _Person_ object types, you cannot save or update the _Person_ record.

Updating these shared fields on a _Person_ record does not update the same fields on referenced _User_ records for <a href="/en/gr/38996/">cross-domain</a>
 and <a href="/en/gr/548356/">VeevaID users</a>
. For cross-domain _User_ records, updates to the _Mobile_, _Image_, and _Manager_ fields are not synced to the _Person_ record. If the _Mobile_ field is blank on a VeevaID _User_ record, Vault does not update the _Mobile_ field on the associated _Person_ record with the blank value.

If you do not specify a user, Vault requires you to populate the _First Name_, _Last Name_, _Email_, _Language_, and _Timezone_ fields manually.

If Admins configure <a href="/en/gr/507990/#duplicate-person">duplicate match rules</a>
 on the _Person_ object, Vault can detect duplicate records when you create a _Person_ record from:

* **Business Admin > Objects** or a custom object tab
* Copying an existing _Person_ record
* Object reference field on a document or object record

A warning may appear beneath the _Email_ field if its input is a match to that of an existing record. Additionally, Vault may disable the **Save** button or prompt you to review similar records in a dialog when it detects duplicate records.

<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>: Ensure the <em>User</em> in the <em>Manager</em> field is associated with a <em>Person</em> record. Otherwise, the <em>Manager</em> field may not sync between the <em>User</em> and <em>Person</em> object. This behavior occurs because the <em>Person</em> object’s <em>Manager</em> field references a <em>Person</em> and not a <em>User</em>.</p>
    </div>
  </div>
</div>



### About Prior Person Records

When a _User_ record is referenced on a _Person_ record, Vault syncs updates to [specific shared fields][6]  on the _User_ record to the _Person_ record. Once the updates are made, Vault creates a _Prior Person_ record with the previous field values before the update. For example, if an Admin updates the _Last Name_ field on their _User_ record from _Jones_ to _Smith_, the _Last Name_ field on the _Prior Person_ record displays the previous _Jones_ value while the _Last Name_ field on the _Person_ displays _Smith_. If the _Prior Person_ record already exists, Vault updates that record with the new previous values.

Vault creates or updates the _Prior Person_ record in the following scenarios:

* If a _User_ record reference is added to an existing _Person_ record, and the shared fields on the _User_ record contain values not available on the _Person_ record
* If the _User_ record referenced on a _Person_ record changes to another _User_ record, and the new _User_ record contains values on the shared fields not on the _Person_ record
* If the shared fields on the referenced _User_ record (including updates via the VeevaID portal) are updated and synced to the _Person_ record

The audit trail displays a record of any changes to the fields on the _Prior Person_ record. Deleting a _Person_ record deletes its _Prior Person_ record. Deleting the referenced _User_ record does not delete the _Prior Person_ record nor change any values.

<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>: The <em>Prior Person</em> record does not contain an <em>Image</em> field.</p>
    </div>
  </div>
</div>



### Reviewing Duplicate Person Records

When duplicate record detection is enabled on the _Person_ object, Vault displays a dialog when it detects you are about to create a duplicate _Person_ record. If you have permission to view at least one of the detected duplicate records, this dialog shows up to 25 results to review.

To review duplicate records:

1. Click the record name to view an existing record in a new tab.
2. Optional: Click **Cancel** to return to your record and make edits.
3. Optional: Click **Create** to proceed with creating the record. Depending on your Vault's configuration, this button may not be available.

You may also need to review duplicate records when creating a _Person_ record from an object reference field on a document or object record. If you have permission to view at least one of the detected duplicate records, this dialog shows up to 25 results to review. Select the new record or an existing record to populate the object reference field. Depending on your Vault's configuration, you may not be able to select the new record and must select an existing record.

## Manager Field Details

Both the _User_ and _Person_ objects contain an optional _Manager_ field with self-referencing relationships to show hierarchy. For example, you can add a related list to the <a href="/en/gr/26387/">object layout</a>
 to display a list of direct reports for a specific user.

The _Person_ object's _Manager_ field references a _Person_ and not a _User_. If the _User_ in the _Manager_ field is not associated with a _Person_ record, the _Manager_ field value may fail to update during the [sync][6] between _User_ and _Person_ object fields.

## Synchronizing Legacy Users and User Object Records {#synchronize-legacy-user-and-user-object-records}

Vault synchronizes _User_ object records with Legacy User accounts and all other Vaults to which the user has membership. Because the _User_ object shares many of the same fields with Legacy User accounts, Vault populates those fields across all Vaults; this includes cross-domain users. Special purpose fields related to authentication, such as the user password, are not included on the _User_ object. Vault does not synchronize updates to custom fields.

<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>: Only users with standard <em>Vault Owner</em> and <em>System Administrator</em> security profiles are allowed to perform updates to Legacy User accounts. Users with custom <em>Vault Owner</em> and <em>System Administrator</em> security profiles are prohibited from performing these updates.</p>
    </div>
  </div>
</div>



## About the Vault Membership Lifecycle {#lifecycle}

Vault provisions the _User_ object with the _Vault Membership_ object lifecycle. The _Vault Membership_ object lifecycle includes the _Inactive_ and _Active_ states, allowing you to change a user's state with a user action.

### Vault Membership Lifecycle Restrictions

The _Vault Membership_ lifecycle has the following restrictions:

#### Membership Lifecycle Details Page

Details
: Only the label and description are editable.

States
: You cannot delete or deactivate the _Active_, _Inactive,_ or _Pending_ lifecycle states. Additionally, you cannot add any new states.

Roles
: Vault runtime does not use role permissions configuration at this time and will be enforced once Vault supports matching sharing rules on the _User_ object in a future release.

#### Membership Lifecycle States Details Page

Details
: Only the state label and description are editable.

Entry Criteria & Entry Actions
: These features are disabled on all states of the _Vault Membership_ lifecycle.

User Actions
: You cannot delete or add conditions to the system actions _Make User Inactive_ (Active state), _Make User Active_ (Inactive states), or _Make User Pending_ (Pending state). However, you can add lifecycle state user actions to any state.

## User References

Vault allows you to create object and document fields that reference the _User_ object. Like other object references, these fields point to the record ID and allow _User_ object fields to be included as lookup fields. When selecting from these fields, you see all active _User_ records in your Vault. Domain users who don't have membership to the current Vault do not appear in the selection menu.

### About Legacy User Reference Fields {#legacy-reference-fields}

In previous releases, _User_ was not an object like _Product_ or _Study_. However, you could still create document and object reference fields to users that did not reference a true object. Although users are now represented as objects, the following document and object fields do not reference the _User_ object:

* Created By
* Last Modified By
* Checked Out By
* Version Created By
* Last Auto-Filed By

### Enabling User Reference Links

To prevent user information from being exposed in your users' Vaults, reference links to _User_ object records are disabled by default. You can choose to enable user reference links, however, we recommend configuring <a href="/en/gr/39108/">Field Level Security</a>
 before doing so. Although some legacy user reference fields do not reference the _User_ object, enabling user reference links allows the _Created By_ and _Last Modified By_ fields to link to _User_ records.

To enable links to _User_ records, navigate to **Admin > Settings > General Settings** and select the **Enable User Reference Links** checkbox.

### Applying Reference Constraints

You can apply <a href="/en/gr/75340/">reference constraints</a>
 on _User_ object fields based on their relationship with the _User_ object. You cannot apply reference constraints onsystem-managed user reference fields that do not reference the _User_ object, such as _Created By_ or _Last Modified By_.

### Configuring Object Page Layouts

You can <a href="/en/gr/26387/">configure page layouts</a>
 for the _User_ object to show related object records referencing the domain user. For example, the _User Role Setup_ object includes the _User_ field, which points to the _User object_. When you add a related object to the _User_ object's page layout, Vault displays _User Role Setup_ as an option.

## Reporting

Managing users with the _User_ object allows you select _User_ as the <a href="/en/gr/21543/">primary reporting object</a>
 and create reports based on user data. For example, you can create a report based on the related _Activity_ object to view productivity or the _Last Login_ field.

[5]: #legacy-reference-fields
[6]: #create-persons
