Working with Data

Unqork offers several options for storing application data. Choosing the right approach affects performance, maintainability, and how easily data can be accessed, updated, and shared.

Storage Options

Unqork supports several internal storage options and the ability to store data in external systems.

Submissions

submissions are the primary internal storage mechanism in Unqork. A submission is a saved record of form data tied to a specific module. Submissions can be created, read, updated, and deleted using Unqork's REST API or through built-in components like the Initializer and Plug-In components.

Use submissions when:

• Data must persist across sessions.
• Creators must query or filter the data.
• Multiple end-users or workflows must access the same data.

See Submission Data Structure and Querying Submissions for details.

Data Collections

Data Collections store reference data that is typically static and can be referenced across the application. Unlike submissions, Data Collections are not tied to a specific module.

Use Data Collections when:

• Data rarely changes.
• The same data must be referenced in multiple modules.

Data Tables in Modules

Data Table components let Creators define and store a collection of data directly in a module. The data is accessible to other components in the same module.

Use Data Tables when:

• Data is specific to a single module.
• A structured, tabular data source is needed without an external API call.

Component-Level Data

Some components, like the Dropdown component, let Creators configure a static list of options directly in the component settings. The data is only available to that specific component.

Use component-level data when:

• Data is small, rarely updated, and relevant to a single component.
• Avoiding a network call on each page load is a priority.

External Systems

Unqork can connect to any external system of record (SOR) that exposes an API. Use the Plug-In component to read from and write to external services.

Use external storage when:

• A third party maintains the data and changes it independently.
• Regulatory or compliance requirements mandate storage outside Unqork.
• An existing system of record must remain the source of truth.

When an external system publishes data on a regular schedule, consider retrieving that data and saving it as an Unqork submission. Doing so avoids performance issues from reading the external source on every page load.

Choosing a Storage Approach

Before deciding how to store data, consider the following:

• Update frequency: How often does the data change? Static data suits component-level or Data Collection storage. Frequently changing data suits submissions or external systems.
• Access frequency: How often is the data read? Storing commonly needed data in Unqork avoids repeated external API calls.
• Data size: Large datasets perform better when stored in submissions or external systems instead of embedded in components.
• Sharing requirements: Data shared across modules or users should be stored in submissions or Data Collections, not at the component level.
• System of record: If Unqork is the new system of record, create a data migration plan to move legacy data into Unqork.
• RBAC: Consider how role-based access control will be implemented for the data. access can be controlled using Unqork roles and permissions.