# Configuring Raw Objects 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](/en/lr/62987/), and you should carefully consider whether to employ this data store option prior to creating one.
## Creating a Raw Object To create a raw object, follow the steps for creating a [standard Vault object](/en/lr/15057/) and select **Raw** in the _Data Store_ field. ## Modifying Raw Objects {#modifying} 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 API. Learn more about deploying changes to raw objects via [configuration packages](/en/lr/36919/) or developer tools.
## Filters for Raw Objects {#filters-indexes} 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: 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][1] for information on and examples of field order. ### About 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 _Raw_ 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.

[1]: #about-field-order