Objects using the Raw object data store option require additional configuration steps beyond a standard Vault object to make their records filterable on custom fields. Raw objects have benefits and limitations, and you should carefully consider whether to employ this data store option prior to creating one.
Note: Raw objects were previously known as high volume objects (HVO).
Creating a Raw Object
To create a raw object, follow the steps for creating a standard Vault object and select Raw in the Data Store field.
Modifying Raw Objects
While a raw object has fewer than 10,000 records, you can modify the object as you would a standard Vault object. However, you cannot modify the raw 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 raw 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 raw objects via configuration packages or developer tools.
Note: During the week of a General Release, we may lock raw objects from configuration changes if they are impacted by data model changes in the release. We recommend not making configuration changes to environments during this week as this can also increase the downtime.
Filters for Raw Objects
While Vault indexes objects using the Standard data store option for search and filtering automatically, Vault indexes raw object metadata differently, using a combination of automatic and up to five (5) custom index definitions. As raw 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 Raw 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 raw object records on custom, non-unique fields:
- Navigate to Admin > Configuration > Objects > [Object] > Indexes.
- Click Create.
- Enter a Label and Name.
- 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.
- 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 example 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.
Related Permissions
|
Type |
Permission Label |
Controls |
|
Security Profile |
Vault Owner |
Ability to modify automatically generated indexes for fields, except Label and Description. |