Form data model and storage

Form schema

A form schema contains:

• pages and their roles;
• global header and footer items;
• layout nodes such as sections and repeaters;
• response and display fields;
• validation and conditional rules;
• variables;
• navigation, theme, regional, localization, publishing, and submission settings.

The canonical JSON is visible through Generate Schema and can be imported through From Schema.

Parent response

The form table prefix identifies generated response storage. Supported response fields become columns with stable field-name identities. Infrastructure columns track IDs, timestamps, form version, trigger relationship, and guarded file/signature metadata.

Changing a respondent label need not change the storage identity. Changing a field name changes the data contract, so review it before you save.

Repeater children

A repeater is a one-to-many relationship. Its field name contributes to the child-table identity and nested fields become child-row columns.

This model preserves multiple attendees, invoice lines, schedule entries, or other repeated records without flattening them into numbered parent columns.

Generated schema and repair

The Forms storage generator compares the active schema with application-domain storage and proposes the required work. It uses the platform data layer and query safety rather than browser-authored SQL.

Display content and completion pages do not create answer columns. File and signature values point to guarded objects rather than embedding unbounded data in response JSON.

Historical data

Removing or renaming a field does not silently erase stored answers. Unlinked identifies stored columns that no longer map to the active form.

Response playback uses the stored form version. This keeps the reading of old responses independent of the current draft.

To act on this model, use Manage versions, schema, and storage. Stored columns and export behavior are listed in the submissions and analytics reference.