# Configuring Vault Objects Vault allows you to easily customize and extend your application data model by modifying standard objects, creating custom objects, and configuring object relationships. ## Accessing Object Configuration You can configure objects from **Admin > Configuration > Objects**. To work on object configuration, you must have the _Admin: Objects_ permissions. ## How to Customize Standard Objects {#customizestandardobjects} To modify an existing, standard object: 1. From **Admin > Configuration > Objects**, click into the object. 2. Click **Edit**. 3. Modify details as needed. Many attributes are not editable. 4. Click **Save**. Generally, the following attributes are editable for a standard object. Depending on your Vault application's data model, you may be able to edit additional attributes, or editing may be blocked on some of these attributes: Label : Value that appears to users as the name of the object-type field. Display in Business Admin : Setting that makes the object appear in the Business Admin component selector. Allow attachments : Setting that enables/disables file attachments on the object's data records. Enable Object Types : Setting to enable or disable object types on the object; this setting is not editable on all standard objects. Matching Sharing Rules : Setting that enables/disables matching sharing rules for the object; when enabled, you must also select a **User Role Setup Object**. Custom Sharing Rules : Setting that enables/disables custom sharing rules for the object. Action Security : Settings that enable/disable the use of Action Level Security to control whether a user can see or execute certain actions on the object's data records, for example, the **Audit Trail** action. Fields : Editable from the **Fields** tab; for standard fields, you can modify the **Label**, **Help Content**, **Description**, [**Values must be unique**,][8] [**User must always enter a value**][9] (limited to certain standard fields), and **Display in default lists and hovercards** attributes, but you cannot modify other attributes, inactivate, or delete fields. You can create custom fields for standard objects. Custom fields are fully editable. You can also add fields to a layout on the object using the **Add to Layout** button. Relationships : Parent-child or referring relationships between objects. Standard (non-customized) relationships are not editable. You can never add a parent object to a standard object. However, you can make a standard object the parent of a custom object or create a reference relationship to or from a standard object. Layouts : Settings that allow you to create up to 20 custom layouts for objects and object types. ## How to Create Custom Objects {#create-custom-objects} To set up a new custom object: 1. From **Admin > Configuration > Objects**, click **Create**. 2. Enter basic details for the new object: label, plural label, and name. The name does not appear to end users and is only visible via Vault API. 3. Optional: Set the status to _Inactive_ to prevent users from creating or modifying object records and to prevent users from viewing or accessing the object. 4. Optional: Set the **Object Class**. To create user task objects, you must set the class to _User Task_. 5. Optional: Set the **Data Store**. Select **Standard** or **Raw**. 6. Optional: Add additional details, including description and custom help content. 7. Optional: Select the **Display in Business Admin** checkbox. 8. Optional: Select the **Allow attachments** checkbox to enable file attachments on object records for this object. To enable Action Level Security for attachment actions, select the **Use Action security to control Attachments** checkbox. 9. Optional: Select the **Audit data changes in this object** checkbox to track object data record changes in the audit logs. 10. Optional: Select the **Relate Multiple Records** checkbox. 11. Optional: Select the **Enable Object Types** checkbox to allow object types within this object. 12. Optional: Select the **Enable Merges** checkbox to enable merges on object records for this object. This allows Vault API or SDK integrations to merge two object records together. 13. Optional: Select the **Matching Sharing Rules** checkbox to enable matching sharing rules for the object. 14. Optional: Select the **Custom Sharing Rules** checkbox to enable custom sharing rules for the object. To enable Action Level Security for the **Sharing Settings** action, select the **Use Action security to control Sharing Settings** checkbox. 15. Optional: Select the **Use Action security to control Audit Trail** checkbox to enable Action Level Security for the **Audit Trail** action. 16. Optional: Select the **Use Action security to control Copy Record** checkbox to enable Action Level Security for the **Copy Record** action. 17. Optional: Select a **Lifecycle** for the object to use object lifecycles. 18. Click **Save**. Once you've created and saved your custom object, you can further configure settings by clicking on the object from **Admin > Objects**. From this page, you can: * Open the **Fields** tab and review the standard fields that Vault creates for the object. For each field, review the [**Values must be unique** setting][8]. * Click **Create** to [add additional fields][18]. * Open the **List** **Layout** tab. Click [**Reorder**][19] and then drag field names to modify the order of object fields. * Open the **Layouts** tab to configure object and object type layouts. ### Displaying Objects in Business Admin {#display-objects} The **Display in Business Admin** setting controls whether users will see the object listed in **Business Admin > Objects**. For example, you can choose to not display objects that non-Admin users will interact with and instead create a custom tab for them. ### Audit Data Changes in this Object {#audit-changes} You can have Vault capture object record data changes in audit logs by enabling the **Audit data changes in this object** setting. Vault always captures changes to object configuration, regardless of this setting. This setting is off by default and only users with appropriate permissions, typically System Administrators and Vault Owners, can enable it. However, if there are existing records in the object, only Vault Owners can enable this setting. Once enabled, Vault logs only new audit events going forward for new and existing records. ### Relating Object Records {#relating-records} The **Relate Multiple Records** setting is only visible on relational (join) objects with two parent objects and only editable for complex many-to-many joins. By default, this setting is cleared. When this setting is enabled, users can relate multiple complex join records from a _Related Object_ section on either parent's object record detail page. Vault automatically creates these records in the background. In order to enable this setting, the complex join object either must have system-managed naming enabled, or the _Name_ field on the complex join object should have the **Values must be unique** setting disabled. This helps prevent record creation from failing. We also recommend that you do not enable the **User must always enter a value** setting on any fields on the complex join object. Finally, ensure that the page layout for each parent object includes a _Related Object_ section for the complex join object so that users can create related records.
### Select All Records in Complex Relationships {#select-all-complex-relationships} If _Relate Multiple Objects_ is enabled, you can also select **Enable Select All** on the same object. This setting is only available for complex many-to-many joins. When this setting is enabled, users can select all records in the _Related Object_ section when relating multiple complex join records. You can select up to 500 records at one time. ### Selecting an Object Lifecycle {#select-lifecycle} You can use object lifecycles with custom objects that you create. If you want to use a lifecycle but haven't yet created it, click **Create Lifecycle** from the **Lifecycle** picklist. You can only assign one object lifecycle to an object. This is required if you enable Matching Sharing Rules. ### Ordering Fields on Record List Pages {#order-fields} You can define the default order of fields in object record list pages using the _List Layout_ tab. This order affects the object details window that displays for end users when they hover over the record label in the Doc Info page. If the _List Layout_ includes child object reference fields, ensure the parent object reference field is also included. If a parent object reference field with the _Display in default lists and hovercards_ setting disabled is not included in the _List Layout_, Vault still displays the field in advanced search dialogs. This behavior occurs because child and parent object fields are tied together and the child object field cannot exist on its own. ### Adding Record Summary Fields {#adding-summary-fields} After adding fields to an object, you can configure up to six _Record Summary Fields_ to display at the top of the object or object type record detail page. These fields will display as users navigate from page to page or layout to layout on the object. All fields on the object or object type are available for selection. If _Record Summary Fields_ are not configured on the object type, the object _Record Summary Fields_ will display. If a _Record Summary Field_ is not available on the object type, it will not display even if configured on the object. When _Record Summary Fields_ are configured on the object type, they will supersede any _Record Summary Fields_ from the object. If a field is deleted from the object or object type, it is removed from the _Record Summary Fields_. ## How to Add Object Fields {#how_to_add_object_fields} You can add new fields to both custom and standard objects. The _Object_ and _Parent Object_ field types will create object relationships, while the _Lookup_ field type utilizes existing object relationships. To add an object field: 1. From **Admin > Configuration > Objects**, click into the object. 2. Click **Edit** and open the **Fields** tab. 3. Click **Create**. 4. Select a **Field Type** from one of the following categories: **Text**, **Number**, **Date & Time**, **Reference**, **Other**. 5. Fill in the remaining attributes, including **Label**, which is the field name that will appear for users. 6. Optional: Enter a **Description** for the field. This is used to assist Admins when configuring the object, and is not visible to users. 7. Optional: Select _Replicate sharing settings from parent object_ to replicate role assignments from a parent object to a child object. This option is only available on object reference fields that reference a parent object with record-level security enabled. 8. Optional: Review the **User must always enter a value (required)** checkbox, if this is available for your field type. 9. Optional: Review the **Values must be unique** setting, if this is available for your field type. 10. Optional: Select the **Display in default lists and hovercards** checkbox to have the field appear in the **Admin** area's object record list view, the object record hovercard in the Doc Info page and record details, the object's _List Layout_ tab, and the object lookup dialog. Some fields with standard data types, such as _Component_ and _ID_, are not displayed in the _Filters_ menu by default. 11. Optional: Select the **Do not copy this field in Copy Record** checkbox to prevent the _Copy Record_ action from copying the source field value to the new record. System fields have this selected by default and cannot be unselected. 12. Optional: Set a **Default Value** for the field, using either a literal value or a formula. Not all field types allow defaults. 13. Optional: Select **Contains Protected Health Information (PHI) or Personally Identifiable Information (PII)**, if this setting is available for your field type. 14. Optional: If available, select a [**Control Binding**][40] value. This option binds the field to a control that becomes displayed in the record detail pages, list views, and related record sections. This option is available only if a control is available, as managed by Veeva. 15. Optional: Set a [**Format Mask**][1] for the field. Not all field types allow format masks. 16. Click **Save**. ### Supported Object Field Types Object fields support the following field types: * Text * [Email][2] * [Link][3] * [Long Text][4] * [Phone][5] * [Rich Text][6] * [Text][7] * Number * [Currency][10] * [Number][11] * [Percent][15] * Date & Time * [Date][17] * [DateTime][20] * [Time][21] * Reference * [Lookup][22] * [Object Reference][23] * [Parent Object][24] * [Roll-up Fields][38] * Other * [Attachment][35] * [Formula][25] * [Picklist][27] * [Yes/No][28] ### Email Fields {#email-field} Email fields allow users to enter and display an email address in the object record. Vault formats the user's input as a hyperlink that opens the default email client of the user who selects it. For example, the input _john.smith@company.com_ is formatted as a hyperlink that opens a draft message in the user's default email client with _john.smith@company.com_ populated in the _To_ field. Vault does not check if the input value is a valid email address. However, you can use the `Regex()` logical function to validate the email address using Record Validation Rules. ### Link Fields {#link-field} Vault formats text entered in a Link field as a hyperlink. Users should enter the full value of a hyperlink in these fields only if it opens a linked destination. For example, entering _www.veeva.com_ in a Link field displays _www.veeva.com_ as a link to the Veeva homepage. When creating a Link field, select _Open link in same window_ to prevent the link's destination from opening in a separate browser tab by default. Vault does not check if the input value is a valid hyperlink. However, you can use the `Regex()` logical function to validate the hyperlink using Record Validation Rules. ### Long Text Fields {#long-text} Long text fields are special text fields that allow users to enter up to 32,000 characters. Long text fields on objects can be used in expressions using the `Left()`, `IsBlank()`, `If()`, and `Case()` functions. #### Limitations * You cannot use tokens for Long Text fields in overlays, signature pages, or messages. * You cannot convert an existing Text field into a Long Text field. ### Picklist Fields {#picklist-fields} When creating a Picklist field, you can select **Use existing picklist** to use an existing picklist instead of creating a new one. Some system picklists such as _Timezone_ are not available for use as an existing picklist. ### Phone Fields {#phone-field} Vault formats values entered in a Phone field in a phone number format. If a user specifies a country code, it is formatted as an international number. If no country code is specified, Vault formats the number using the North American Numbering Plan. For example: * Input _+34932719725_ = _+34 932 71 97 25_ * Input _19254526500_ = _1 (925) 452-6500_ * Input _9254526500_ = _(925) 452-6500_ Users can enter non-numeric characters, such as _1-800-CABLETV_, or use their own formatting, such as _(456) 789-1234_. Vault will not attempt to format these inputs further. ### Rich Text Fields {#rich-text-field} Rich text fields are special text fields that allow users to apply common formatting options, including font family, size, text decorations, alignment, lists, scientific notations, and links. Vault applies text formatting using HTML and supports up to 32,000 plain text characters, configurable when creating a rich text field, and a combined maximum of 64,000 plain text and HTML markup characters, a limit which cannot be modified. For example, `Hello` has five plain text characters and seven HTML markup characters which equals twelve characters total. Rich text fields created through Vault and API only support certain HTML tags and attributes, which you can download here. You can use rich text fields on objects in expressions using the `Left()`, `IsBlank()`, `If()`, and `Case()` functions. #### Adaptive Rich Text Editor {#adaptive-rich-text-editor} Rich text fields and sections provide an adaptive rich text editor that includes the formatting options mentioned [above][6]. The adaptive rich text editor behaves as follows: * To use the adaptive rich text editor, click the rich text field or section while editing an object record. Otherwise, only the field content displays and none of the formatting options are available. * When you click a rich text field or section, only that field's adaptive rich text editor is displayed for use. If you click another rich text field, the previous field's adaptive rich text editor is closed. * While interacting with the adaptive rich text editor, undo and redo actions are available. Once you switch to a different rich text field, the undo and redo actions are no longer available for the previous field and only apply to the current field. #### Limits * Users must apply text format using the formatting toolbar or copying and pasting text into the rich text field. If users manually type HTML markup into a rich text field, Vault treats it as plain text. * The rich text formatting toolbar does not appear to users on mobile devices, though users can format text using their device's native text formatting toolbar. * Vault displays rich text _Merge Fields_ as plain text. * Vault does not support rich text fields in _Merge Fields_ barcodes. * Vault does not support creating tables through the adaptive rich text editor. However, you can copy and paste plain text tables into rich text fields. The converted plain text uses spaces and new lines to maintain a readable layout, while stripping out table formatting and font styles. All text content and links are preserved once the table is pasted. ### Text Fields {#text-field} Text fields allow users to enter anything the user types to the maximum specified length. ### Currency Fields {#currency-field} Currency fields allow users to enter a monetary amount, which Vault then displays throughout the UI according to the user's locale. Adding the first Currency-type field to an object creates an additional _Local Currency_ (`local_currency__sys`) field and each Currency-type field creates a related corporate currency field. ### Number Fields {#number-field} Number fields allow users to enter numbers. Vault applies error checking based on the specified minimum value, maximum value, and decimal place. ### Percent Fields {#percent-field} Percent fields allow users to enter a number value that Vault converts to a percentage. The percentage is dependent on the **Minimum Value**, **Maximum Value**, and selected **Decimal Places** value (0-9). Vault drops trailing zeros in decimal percentages. For example: * 51 = 51% * 51.10 = 51.1% * 51.745 = 51.745% Before setting the **Minimum Value**, **Maximum Value**, and **Decimal Places** fields, convert the percentage values you want to allow into a number format. For example, 65% equals 0.65 and 99% equals 0.99. If you want users to enter values such as 51, 65, or 100, you would configure: * Minimum Value: 0 * Maximum Value: 1 * Decimal Places: 2 Vault then converts these values into whole percentages at runtime: 51%, 65%, 100%. This configuration does not allow decimal percentages, because these would add more than two (2) numbers after the decimal place. For example, 65.5% converts to 0.655 as a number while 65% converts to 0.65. In addition, 6.5% converts to 0.065. If you set **Decimal Places** to one (1), Vault allows no more than one (1) number after the decimal. Therefore, users can only enter percentages in multiples of 10, such as 10 for 10% and 20 for 20%. This happens because the number format contains only one number after the decimal, such as 0.1 for 10%. In addition, if you want a user to enter a value such as 25.92%, you would need four (4) decimal places because 25.92% equals 0.2592 in a number format. ### Date Fields {#date-field} Date fields allow users to enter a date either by typing in MM/DD/YYYY format, or by clicking the calendar icon and selecting the date. Date fields also include a _Today_ link that users can click to easily set the value to the current date. ### DateTime Fields {#datetime-field} DateTime fields allow users to enter a combined date and time value: Day Month Year Hour:Minute AM/PM Time Zone. For example: 04 May 2014 11:27 AM EDT. ### Time Fields {#time-field} Time fields allow users to enter a time either by typing in values manually, or by selecting a time from a selector. Vault displays the user's time input according to their locale settings. For example, if a US user enters _1:30 PM_, German users will see _13:30_ instead.The time closest to the user's current time is highlighted by default in the time selector. When users are editing a Time field, they can also click the _Now_ button to update the value to their current time. ### Lookup Fields {#lookup-field} Vault displays a field value from parent or referenced object relationships on Lookup fields. When creating a Lookup field, you must select the related object record and field. ### Object Reference Fields {#object-reference-field} When creating an object reference field on an object, you can link to any object, such as the _User_ object, or you can link to the _Document_ object to create a document reference field. ### Parent Object Fields {#parent-object-field} Parent Object fields allow you to create a parent-child relationship between this object (the child) and another object (the parent). When creating an object reference field on an object, you can link to the _Document_ object to create a document reference field. You cannot create a _Parent Object_ field on an object with existing records. In addition, adding a _Parent Object_ field removes any field-level security on the object. You can create up to two _Parent Object_ fields per object. ### Roll-up Fields {#roll-up-fields} You can configure Roll-up fields on parent objects to display a calculated **Minimum**, **Maximum**, **Count**, or **Sum** value based on a _Roll-up Source Field_ value (Number, Currency, Date, and DateTime) on related child records. The Roll-up field value is recalculated whenever a child record in the inbound relationship is created, updated, or deleted. For example, you could add a _Total Amount of Expenses_ Roll-up field to an _Expense Report_ parent object that calculates all _Expense Amount_ fields across related _Expense Item_ child records. The _Total Amount of Expenses_ field updates anytime an _Expense Amount_ field is added, deleted, or updated. If a parent record contains 100 child records or less, Vault performs the calculation synchronously, meaning the value displays in the Roll-up field as soon as the calculation finishes. If there are over 100 child records, Vault performs an asynchronous calculation, meaning the calculation runs in the background. In this case, the value is displayed once the background calculation is complete. When creating a Roll-up field, you must select a _Roll-up Source Field_ from the related child object and a _Roll-up Function_. You can only select one _Roll-up Source Field_ per Roll-up field. You can also use a boolean true/false formula expression to exclude or include child records with the _Roll-up Source Field_. You can select one of the following **Roll-up Functions**: * **Minimum**: Displays the minimum value present amongst each _Roll-up Source Field_ on related child records. * **Maximum**: Displays the maximum value present amongst each _Roll-up Source Field_ on related child records. * **Count**: Displays the total number of related child records with an inbound relationship to the parent object. This function does not require a _Roll-up Source Field_. * **Sum**: Displays a sum of all values from the selected _Roll-up Source Field_. This function only supports Number and Corporate Currency fields. You can initiate a full recalculation of all Roll-up fields on an object's parent records by clicking **Recalculate Roll-up Fields** on the object's _Details_ tab. This action is helpful in the following scenarios: * When adding a new Roll-up field, Vault does not automatically calculate a value for existing parent records. In this case, you can use the **Recalculate Roll-up Fields** to perform a bulk roll-up calculation of all Roll-up fields on an object. * If you upload a large amount of records via Record Migration Mode, Vault bypasses automatic roll-up calculation. You can manually calculate the new values of the Roll-up fields and add them within the CSV input file before loading the records in _Record Migration Mode_. Using this method to load records eliminates unnecessary processing, which results in faster load times. You can also add an initial value, such as a blank/null value, to the Roll-up fields in the CSV input file during the data load. Once all records are loaded, click **Recalculate Roll-up Fields** to process the new records. This method may invoke more processing time depending on the amount of Roll-up fields defined on the parent object. Please consider the full behavior of _Record Migration Mode_ when determining if this approach is a viable alternative to meeting your requirements. Each Roll-up field adds additional processing time on record operations as Vault must not only perform standard record operations, but also recalculate each Roll-up field on parent records. Therefore, you may experience an increase in data operations with each new Roll-up field. Roll-up fields are not recommended for child objects with the following behaviors: * Display the potential to possess, or already possess, more than 500,000 records * Contain integration with 3rd party systems * Encounter a high volume of changes, such as record inserts, updates, and deletions, on a recurring basis
#### Limitations * Parent object records support up to 25 Roll-up fields. * Roll-up field calculations are performed in the corporate currency and cannot perform currency conversions. * If a synchronous roll-up calculation exceeds 100 seconds, Vault performs the calculation asynchronously instead. * Null values within a _Roll-up Source Field_ are excluded from all roll-up calculations and functions. * You cannot select another Roll-up field from the _Roll-up Source Field_ picklist. * Roll-up fields are available only if the object contains an inbound relationship to a child record. * You cannot use the following fields in Roll-up formula expressions: Attachment, Formula, Lookup, Object, Parent Object, Long Text, Rich Text, and Roll-up. ### Attachment Fields {#attachment-fields} _Attachment_ fields allow users to attach a single file to a field on the record. Users can upload, download, and remove files from this field. Unlike the _Attachments_ section, _Attachment_ fields can be controlled by field level security and atomic security, similar to all other object field types. You can add up to 15 _Attachment_ fields per object, and one file per field. You can also add _Attachment_ fields as a column on the object record list page, which allows the same upload, download, and remove functionality available on the object record layout. You cannot delete an _Attachment_ field if it is referenced in another component, for example, if the field is in use on at least one record, a formula expression, or validation rule. Used in conjunction with the `isBlank()` function or lifecycle state entry criteria, you can use layout rules and validation rules to ensure an _Attachment_ field is populated at specific points in a lifecycle. #### Limitations * You can upload files up to 100 MB in size * _Attachment_ fields are not supported on raw objects. * Vault does not render files uploaded to _Attachment_ fields. You can only view these files by downloading them. * File names cannot exceed 215 bytes, including the file extension. One (1) character does not always equal one (1) byte. For example, the character 菌 is three (3) bytes. * _Attachment_ fields are not versioned. * You cannot add a description to _Attachment_ fields. * You cannot search for files uploaded to an _Attachment_ field using the attachment's content and must use the file name. ### Formula Fields {#formula-field} You can create a _Formula_-type field on an object to show either a calculated value or an icon. For details about adding _Formula_ fields, see Configuring Formula Fields on Objects. ### Picklist Fields {#picklist-field} When creating a _Picklist_ field, you can select **Use existing picklist** to use an existing picklist instead of creating a new one. Some system picklists such as _Timezone_ are not available for use as an existing picklist. ### Yes/No Fields {#yes-no-fields} When creating a _Yes/No_ field on an object, you can select **Show as checkbox** to display the field as a checkbox instead of a _Yes_ and _No_ radio button. When you select this option, the checkbox displays in the object record list page grid, and on the object record details page. _Yes/No_ fields have three (3) states: _Yes_, _No,_ or _null_. _Yes/No_ checkbox fields on new object records have a _null_ value unless a default value is configured. If you select a _null_ checkbox, Vault updates the value to _Yes_. Then, if you clear the checkbox, Vault sets the value to _No_. Once a user selects or clears a _null_ checkbox, they can only set it to _null_ again through Vault API or Vault Loader.
### Record Validation Rules {#record-validation-rules} You can configure validation rules for object records to ensure that users enter meaningful and correct data by checking object field values. A validation rule contains a formula or expression that evaluates the user-entered data on a field and returns "True," meaning that the data is valid, or "False," meaning that the data is invalid. ### Required Setting {#required} Within some fields' configuration, there is a **User must always enter a value (required)** setting. When this setting is enabled, users cannot create or save changes to object records if this field is blank. You cannot enable this setting for object and document reference fields if the field's [**Deletion Rule**][33] is **Set field to blank when related document is deleted**. ### Values Must be Unique Setting {#values} Within some fields' configuration, there is a **Values must be unique** setting. For every object, there are some fields where each record must have a unique field value (like _Name_ or _External ID_) and others that do not need to be unique (like _Therapeutic Area_ or _Product_). In hierarchical objects, Vault only enforces uniqueness for records that share the same parent. When editing an object field, the system applies changes to this setting asynchronously, meaning that there may be a delay before the change takes effect, particularly on Vaults with a lot of activity. While the system is processing these changes, Vault will block certain actions on the affected field, including deleting the field and modifying the _Maximum Length_ setting. You cannot clear this setting if the field is in use in a default value expression. ### Pre-Default Object Reference Field Setting In the _Object_ field type configuration, there is a **Pre-default on non-required field when only one reference record is available** setting. When this setting is enabled, Vault pre-populates the optional object reference field when there is only one (1) record available on the referenced object. This setting applies to document and object reference fields. This behavior only applies when creating or copying records on the object record details page and not during background processes, such as API calls. ### Control Binding {#control-binding} Vault allows you to bind an object field to a control, which augments the display of object fields in record detail pages, list views, and related object sections. Object fields with a control binding always display as configured by the control binding in any object layout. Controls are created and managed by Veeva, and each application family may support different controls, or none at all. New features released by each application family may use control bindings. Please refer to these in the Release Notes and application family specific Vault Help pages. When selecting a control binding, Vault may prompt you to select properties that are specific to that control. You can edit the properties after saving the field by clicking _Edit Properties_. Veeva manages when control bindings should be available for a field. If no control bindings are available for a field, the _Control Binding_ field is hidden. When adding an object field with control binding to an object layout, an icon () displays next to the field in the Layout Editor. Hover over the icon to display all control binding properties configured for the field. If a Long Text or Rich Text field using a control binding is added to a layout as a Text section, the section does not inherit any control behaviors and operates as a normal Long Text or Rich Text section. Object type fields can override the control on the base object field in the following scenarios: * Overrides can add a control binding specific for that object type. * Overrides cannot remove a control binding on the base object field; it can only be modified to another control or same control with different properties.
## Format Masks {#format-masks} You can set a format mask on an object field to configure how text and number fields display in Vault. When creating a Text or Number field, navigate to Step 5 to create a format mask. The _Formats_ tab provides Phone, Link, Email, and Time formats for Text fields and Percent formats for Number fields. The Email and Link format options display the user's input as a hyperlink. For example, if a user enters an email address, they can use this hyperlink to open a new email in their mail application. The Email and Link formats do not verify that the user has entered a valid email address or URL, though you can accomplish this with validation rules using the `Regex()` function. You can also configure your own format mask expressions using Vault formula expressions. Format masks are only available for Text and Number fields, lookup fields with a Text or Number field as the source, and formula fields that return a Text or Number field. You cannot configure format masks for standard Text and Number fields within the following: * First Name, Last Name, User Name, and Veeva ID fields on _Person_ object * First Name, Last Name, and User Name fields on _Prior Person_ object * EDL-related objects (EDL, EDL Item, EDL Template, EDL Item Template)
### How to Configure Format Masks To configure a format mask: 1. In the _Format Mask_ section, select **Formats**. 2. Select your desired format from the **Search Formats** picklist. 3. Click **Check Syntax** to verify your expression is valid. 4. Optional: Use the _Preview Tool_ to display an example of the format mask as it will appear on the user's end. For example, if you are using the LinkFormat() function and enter "www.veeva.com" in the **Value Entered** field, the **Value Displayed** field populates "www.veeva.com" in a hyperlink format that opens the Veeva home page. 5. Click **Save**. The user will now see your format mask whenever they interact with the formatted field on the object.
## Add Fields to Object Layout Once you've created a new field, you can add it to an object or object type layout. This action applies to new and existing fields. Click on the field in the _Fields_ tab, and then click **Add to Layout**. A _Select Layout_ window appears with all active layouts available on the object. If the field is already added to a layout, that layout is grayed out for selection. Select the layout and click **Done**. The next time you add fields to a _Details Form_ section on the layout, the new field will appear for selection. ## Field-Level Encryption for PHI & PII {#protected-info} All Vault data is stored securely by encrypting the data at rest. For sensitive information like Protected Health Information (PHI) and Personally Identifiable Information (PII), Vault offers double encryption for field values. To mark a field as PHI/PII: 1. Select an object from **Admin > Configuration > Objects**. 2. Select a field where you want Vault to add additional protection. Vault cannot add additional protection on system fields, formula reference fields, object reference fields, document reference fields, picklist-type fields, or fields that already have values. 3. Enable the **Contains Protected Health Information (PHI) or Personally Identifiable Information (PII)** option. Vault provides additional security for values entered into fields by adding a second layer of protection in the unlikely event of a security incident. You can only enable this option for a maximum of ten fields per object. #### Additional Considerations For configuration objects that are cloned during sandbox creation, encrypted field values are exempt and will be blank instead. In Object Record Audit History, encrypted fields are masked (\*\*\*\*\) by default. Admins can use the _Show PHI or PII values_ action to show the decrypted values instead. When viewing the audit trail for a specific record, encrypted fields are not masked. ## Document Security with Custom Objects Custom objects do not have the same functionality as standard objects. If your Vault uses non-DAC document security, you cannot use custom objects for default role assignment overrides. For example, you could choose to default different users into the _Reviewer_ role based on the country selected for a document because _Country_ is a standard object. You could not do this with a custom object. ## How to Enable Create & Relate Records It's possible to create and relate object records without leaving the context of the original record. This option is only available for objects related through an object reference field or a simple relational object. You can also create and relate object records from document fields that reference an object. You must enable this feature for each individual object reference field. 1. Open the object in **Admin > Configuration > Objects > {Objects}**. 2. Click **Fields**. 3. Click on the object reference field (Object or Parent Object field type). 4. Click **Edit**. 5. Select the **Allow create new reference record checkbox**. 6. Click **Save**. ## How to Reference Objects in Document Fields Once you have created an object, you must create a document field that corresponds to it in order to allow users to associate an object with a document. Most steps of the document field creation process are detailed in Managing Document Fields. To create an object-type document field: 1. Follow the basic steps to create any new document field. 2. After selecting _Object_ as the field type, enter a **Label**. This label, not the actual object's label, will appear to end users. 3. Under Step 3, select an object to which the field should map. Object-type fields will work much like picklists for the end user, but the picklist options are managed as object data records in **Business Admin > Objects**, rather than as picklists. 4. If your field maps to a child object, select the parent object's document field in the **Controlling Field** picklist. ## How to Modify Business Admin Layout You can choose to prevent objects from displaying here by clearing the **Display in Business Admin** checkbox in the object configuration. If you prevent a child object from displaying, Admin users can still create data records for the object from within the parent data record. Object data records can also appear outside of Admin if your Vault includes custom tabs. ## Limitations on Object & Object Record Deletion In some situations where an object is in use within your Vault, you will not be able to delete it. In these cases, you can change the object's _Status_ to _Inactive_ to prevent users from accessing the option without compromising configurations or document metadata. To fully disable a custom object so that users cannot make selections for it within document fields, you must also change the status for the document field. Standard objects can never be deleted or disabled. ### Object Record Deletion & Relationships {#relationships_deletion} When creating object reference fields and defining relationships between two objects, you also define deletion rules. This setting affects how Vault behaves when you attempt to delete an object record that is either the parent object record in a parent-child relationship or the referenced object record in a reference relationship. The **Deletion Rule** options are: Prevent deletion of the related object record : This option prevents you from deleting an object record if it is selected as a parent object record or as a reference object record. For example, you cannot delete a product if there are marketing campaigns with that product selected as their parent. You also cannot delete an agency if the agency is referenced by marketing campaigns. Cascade delete children records : This option is only available for parent-child relationships. For Vaults using the RIM Submissions application, the Submission object has a self-reference relationship that also supports cascade delete. When you delete an object record, Vault also deletes any object records that have the deleted record as their parent. For example, deleting a product deletes all child marketing campaigns. When you delete more than 1,000 records, Vault deletes records asynchronously in a background process. You will be notified when the process completes. Set field to blank when related record is deleted : This option is only available for reference relationships. When you delete an object record that is referenced by another object record, Vault resets the referencing field to be blank. For example, when deleting an agency, the _Agency_ field on all marketing campaigns with that agency becomes blank.
## Limitations {#object-limitations} Vault enforces certain limits to ensure that users don't experience performance issues: | Type | Limit | | --- |--- | | Custom Objects | Up to 500 custom objects per Vault | | Unique Custom Fields on Objects | Up to 25 unique custom fields assigned to each standard data store object. Up to ten (10) unique custom fields assigned to each raw data store object. | | Custom Fields on Objects | Up to 800 custom fields assigned to each standard data store object. Up to 500 custom fields assigned to each raw data store object. | | Custom Formula Fields on Objects | Up to 50 custom formula fields assigned to each object. | | Long Text Fields on Objects and Object Types | Up to 50 Long Text and Rich Text fields combined per object (standard and custom) | | Rich Text Fields on Objects and Object Types | Up to 50 Long Text and Rich Text fields combined per object (standard and custom) | | Lookup Field Relationships on Objects | Up to ten (10) lookup relationships per object | | Lookup Fields on Relationships | Up to 20 lookup fields per lookup relationship | | Custom Object Types | Up to 50 custom object types per object | | Object Records | Up to 100,000,000 records per standard data store object. Up to 1,000,000,000 records per raw data store object. | | Custom Outbound Relationships | Up to 20 relationships per object | | Custom Inbound Relationships | Up to 50 relationships per object | | Custom Fields with Control Binding | Up to 20 per object and 20 per object type |
[1]: #Format_Masks [2]: #email-field [3]: #link-field [4]: #long-text [5]: #phone-field [6]: #rich-text-field [7]: #text-field [8]: #values [9]: #required [10]: #currency-field [11]: #number-field [12]: #display-objects [13]: #audit-changes [14]: #relating-records [15]: #percent-field [16]: #select-lifecycle [17]: #date-field [18]: #add-fields [19]: #order-fields [20]: #datetime-field [21]: #time-field [22]: #lookup-field [23]: #object-reference-field [24]: #parent-object-field [25]: #formula-field [26]: #protected-info [27]: #picklist-field [28]: #yes-no-fields [33]: #relationships_deletion [34]: #adding-summary-fields [35]: #attachment-fields [36]: #record-validation-rules [37]: #picklist-fields [38]: #roll-up-fields [39]: #adaptive-rich-text-editor [40]: #control-binding