Configuring a Datastore

General Settings

A datastore's general settings consist of the datastore's name, slug, and description. These will all appear on the datastore home (Home > Settings > Datastore) to allow you to select the right datastore to search in.

Note, though, that you are likely building datastores for use a data repositories to be used by other Services. These other services will use the bridges (if connecting in the form builder) or the slug (if connecting in the workflow) to access this data.

Table Properties

This section of the configuration controls what is when searching in the datastore from the datastore home. This is the default index, sort order, and display fields.

Bridge Configuration

The bridge configuration is how you will search from within the form builder of a Service to this datastore. You will want to be sure to select Kinetic Core for the Bridge name. Then, you will set up the qualifications and mappings you need.

ExampleBridgeQual1Bridge qualifications are essentially searches that you are going to allow the Services to do. For example, you could set up a search for all active records. Or perhaps one for all records where a certain fields matches a parameter the Service will pass in. It is both flexible and controlled. You can set up pretty much any search you can think of, but form developers don't need to understand the data to be able to search it. They simply use the qualification provided and pass the requested parameters and they get back the data they need.


Qualifications can be single or multiple result. You'll want to make sure that option is selected correctly, because if a single qualification returns multiple results, it will error.

The Qualification may have no parameters or one parameter or multiple parameters, whatever is appropriate for your search. It is important that the search parameters align, though, with the index provided for the search. For example, if the search is for state, the index should be state (see example above). The Query must contain:

  • index={a valid index for the form}
  • formSlug={the form slug}
  • the rest of the search query

Fields of the form itself are referenced directly (id, handle) but fields place on the form in the form builder will be in the values array and are accessible as values[field name]. Parameters are available in the query as ${parameters('parameter name here')} as shown in the example above.


Mappings are the fields that will be returned by the searches and what they will be called for the recipient. These can map exactly to the fields, but they don't have to. Say you have first and last name fields but you also want to pass a Full Name field back to the Services. You can do that by creating a mapping Full Name and mapping both First and Last name into that.