Understanding Datastore Indexes

Any search on a Datastore Form needs to correspond to an index on that form. For example, if you had a wanted to be able to search by age on a people datastore, age would need to be an indexed field on that datastore.

Datastore Forms will automatically set up indexes for each field on the 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 (1000 desired in this case), the index, and the query.

Use of a combined index could look like this:

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