Objects using the High Volume object data store option require additional configuration steps beyond a standard Vault object to make their records filterable on custom fields. High volume objects have benefits and limitations, and you should carefully consider whether to employ this data store option prior to creating one.

Creating a High Volume Object

To create a high volume object, follow the steps for creating a standard Vault object and select High Volume in the Data Store field.

Modifying High Volume Objects

While a high volume object has fewer than 10,000 records, you can modify the object as you would a standard Vault object. However, you cannot modify the high volume object in the following ways in Vault if it has 10,000 or more records, except via configuration packages or developer tools:

  • Add or remove fields
  • Change the length of any variable-length field, such as Text, Long Text, or Rich Text
  • Create indexes
  • Enable lifecycles
  • Enable or disable object types

When deploying changes via a configuration package or developer tools, a high volume object displays the status of impending changes in Admin > Objects > [Object] > Details, next to the Status field. While an object has impending changes, you cannot edit fields, list layouts, or indexes, but users can continue to interact with object records. Impending changes can have the following statuses: In Deployment, Cancelling, or Error. The Cancelling status only appears if an API user has chosen to cancel an in-progress modification with the Vault REST API. Learn more about deploying changes to high volume objects via configuration packages or developer tools.

Filters for High Volume Objects

While Vault indexes objects using the Standard data store option for search and filtering automatically, Vault indexes high volume object metadata differently, using a combination of automatic and up to five (5) custom index definitions. As high volume objects do not use the standard Vault advanced search, you may want to consider what types of filters your users will need. You can then define custom indexes to meet those needs.

Automatic Indexing for High Volume Objects

Vault automatically indexes the following system fields: ID, Name, Modified Date, Status, Object Type (when applicable), and State (when applicable). Vault automatically creates indexes when a field is made unique or when a relationship field is added. Vault removes such indexes if the field is later made non-unique or the relationship field is removed.

Vault names automatically created indexes after the field that caused the indexing. For example, saving a custom field named Order after selecting the Values must be unique checkbox causes Vault to create an index named order__sys.

Creating a Custom Filtering Index

To create an index which allows users to filter high volume object records on custom, non-unique fields:

  1. Navigate to Admin > Configuration > Objects > [Object] > Indexes.
  2. Click Create.
  3. Enter a Label and Name.
  4. In the Fields (In Order) section, select a field in the Field 1 drop-down. Note that Vault only displays indexable fields in this drop-down. Vault cannot index Text, Long Text, or Rich Text fields longer than 255 characters.
  5. Optional: Add additional fields by clicking the + icon next to the drop-down. See About Field Order for information on and examples of field order.

About Field Order

Vault uses indexes defined on an object to speed up search pages. Index entries are first sorted by the field selected as Field 1, then entries with equivalent values for Field 1 are sorted by Field 2, and so on. The order of fields in the index is important when determining whether that index can optimize a search containing filters.

Example 1

Suppose your users typically want to execute a search, filtering on a date range with the field Date. In this case, only indexes that begin with Date can optimize the search performance, such as Field 1: Date, or Field 1: Date, followed by Field 2: Affected ID. An index which contains, but does not start with Date, such as Field 1: Affected ID, followed by Field 2: Date could not be used to optimize this search.

Example 2

Suppose your users typically want to execute a search filtering on a date range with the field Date, and where the User ID field has a particular value. The following indexes could be used to optimize the search:

  • An index beginning with Date, such as Field 1: Date, or Field 1: Date, followed by Field 2: Affected ID.
  • An index beginning with User ID, such as Field 1: User ID, or Field 1: User ID, followed by Field 2: Affected ID.
  • An index beginning with Date and User ID, such as:
    • Field 1: Date, followed by Field 2: User ID
    • Field 1: User ID, followed by Field 2: Date
    • Field 1: Date, followed by Field 2: User ID, followed by Field 3: Affected ID

In this case, indexes 1 or 2 can provide some level of optimization, but index 3 provides a greater level of optimization. When given a choice of multiple indexes, Vault will choose the index that it expects to provide the greatest level of optimization.

The following examples index could not be used to optimize this search: An index which contains Date or User ID but does not start with either, such as Field 1: Affected ID, followed by Field 2: Date, followed by Field 3: User ID.

Example 3

Suppose your users typically want to search for records where User ID is not a particular value. In general, indexes cannot be used to optimize queries with negation operators such as “not equals”. If this is a common use case, the High Volume object data store option may not be appropriate for the object.

Type

Permission Label

Controls

Security Profile

Vault Owner

Ability to modify automatically generated indexes for fields, except Label and Description.