Skip to main content
Kinetic Community

Datastore Forms vs Kapp Forms

Overview of Problem that Datastore Forms Solve

When working with large datasets, understanding how users need to query for data is very important to keep a system healthy and fast. Traditionally application owners would rely on a Database Administrator to design a database schema that was properly indexed for speedy searches.  In the Kinetic platform, users can define their own fields (think of them as columns in a database). Datastore Forms allow system admins to define combinations of fields that users will need to query by. The application then builds index records behind the scenes to make sure that query will execute quickly on large datasets.

Forms vs Datastore Form Comparison

There are a few key differences between [regular] Forms and Datastore Forms. The primary difference is in the way one queries for Submissions (or records created) of one of these forms.

 

Kapp Forms

Datastore Forms

Optimized For

Transactional Data

Forms are used for capturing data that has a defined beginning and end date (life cycle). Common use cases would be Orders, Requests, Incidents, Cases or Work Orders.

Referential Data

Datastore Forms typically store data that doesn’t have a defined life cycle and has a well defined querying pattern. Common use cases would be Assets, Sites, Vendors, or Cities and States. (deterministic)

Scoped To

Kapp

Forms exist within Kapps (Kinetic Apps). A Kapp represents a collection of forms typically used to create an app. An example of Kapp would be a Service Catalog (collection of user requestable items) or a Case Management System.

Space

Datastore Forms exist at the Space level of the Kinetic Platform. These forms are typically used to store data that needs to be shared between all Kapps. An example would be a list of Sites that both the Service Catalog Kapp and Case Management kapp leverage to build up Site Lists.

Search across Forms

Yes

Submissions within a Kapp can be searched regardless of form by using a predefined set of fields (Kapp Fields). An example of a query like this would be Submissions in a kapp where the Assigned Team is HR. This query didn’t include a specific form, and is valid because Assigned Team is a Kapp Field.

No

Datastore Submissions have no shared (pre-defined) fields. You can only search for submissions in a single Datastore at a time.

Ensures Uniqueness

No

Forms don’t allow form administrators to define uniqueness restrictions on submissions.

Yes

Datastore Forms allow administrators to set uniqueness restrictions on submissions. An example would be a datastore representing States. You would want to ensure that the State Name field would be unique, so that two submissions couldn’t have the same State Name.

Search & Sort Strategy

Ad-hoc Size Dependant

Form Submissions can be searched using an ad-hoc pattern (ANDs/ORs) and the sort order is limited to a timeline (createdAt, submittedAt, UpdatedAt, closedAt). This style of searching is considered to be non-deterministic when using ANDs in the query (because an error is thrown if none of the individual comparisons match less than 1000 results for the specified timeframe) .

Predefined - Admin Defined Patterns

Datastore Form Submissions are queried using predefined patterns configured by the forms administrator. Large result sets can be returned in a paginated fashion and sorted in the order defined by the index. This style of searching is considered to be deterministic.