Understanding Datastore Indexes

Each search term in a datastore form must correspond to an index on that form. For example, if you had want to search a "People" datastore form by age, you would need to add an "Age" index field to the form.

An index is created automatically for each field you add to a datastore form.


You will need to trigger a build for these indexes before they can be used. This is only needed right after the field(s) are added to the form. Note that if you at a later time add another field, you will need to trigger indexing again.

There are also a series of system fields that are indexed for each datastore form:

  • createdAt
  • createdBy
  • updatedAt
  • updatedBu
  • submittedAt
  • submittedBy
  • handle

Compound Indexes

Compound (or multi-field/property) indexes on Datastore forms can also be defined. Each field/property defined in an index is referred to as an index part. A query for “All people with the first name Tony living in Maine between age 50 and 60” would be possible by creating a compound index with parts First Name, State and Age. All of the existing user and system fields are available when creating a compound index.



Uniqueness restrictions on submissions can be enforced via a unique index. An example would be a datastore representing Countries. You would want to ensure that the Country Name field would be unique, so that no two submissions could have the same Country. When defining or editing an index, you can specify the “Unique” flag.



Queries need to then specify the index to use when searching the datastore form. For example, this would be a bridge qualification for a test-dataset form for all active records:


It specifies the datastore form to use, the limit (in this case, 1000 records), the index, and the query.

A combined index query could look like this:

formSlug=test-dataset&limit=1000&index=values[Make],values[Model],q=values[Make] = "${parameters('Make')}" AND values[Model] = "${parameters('Model')}"