Schemas

The data model behind every form — fields, validation rules, and layout structure.

What is a Form Schema?

A form schema is the complete definition of a form. It describes everything about the form in a single, structured package: which fields to display, what data to collect, how to validate user input, and how to arrange the form visually. When you build a form in the form builder, you are creating and editing a schema behind the scenes.

Think of the schema as the blueprint for your form. It contains all the instructions needed to render the form consistently, validate submissions correctly, and process responses appropriately.

Two Parts Working Together

Every form schema has two complementary parts:

The Data Schema — What to Collect

The data schema defines the information your form collects. For each field, it specifies:

Field name — A unique identifier for each piece of data (e.g., "email", "company_name")
Data type — Whether the field expects text, a number, a yes/no value, a date, or a list of values
Required fields — Which fields must be filled in before the form can be submitted
Allowed values — A predefined list of options for dropdown or radio button fields
Validation rules — Constraints like minimum/maximum values, text length limits, or format requirements (e.g., must be a valid email address)

The Layout Schema — How to Arrange It

The layout schema controls how the form appears to users. It defines:

Sections — Groups of related fields under a shared heading (e.g., "Contact Information", "Preferences")
Rows — Side-by-side field arrangements using a flexible grid (e.g., first name and last name on the same line)
Tabs — For complex forms, organize sections into switchable tabs to reduce visual clutter
Field placement — The order in which fields appear and which input control each field uses
Display elements — Non-data elements like headings, help text, dividers, and alert banners that guide the user

The form builder handles both schemas automatically. When you drag a text field onto the canvas, it creates both the data definition (what to collect) and the layout definition (where to show it) at the same time.

Schema Types

Every form schema has a type that determines how submissions are handled:

Type	Purpose
Submission	Public-facing forms for collecting data from your audience. Supports anonymous submissions and optional profile creation from form data.
Internal	Organization-only forms for internal workflows. Only accessible to authenticated team members.
Work Ops	Forms that automatically create tasks in Work Ops when submitted. Form fields map to task properties like project, priority, and assignee.

Versioning

Every time you save a form, the version number increments automatically. This gives you a clear history of how the form has changed over time. Version numbers are simple integers — version 1, version 2, version 3, and so on.

Versioning is automatic and requires no extra steps. Just save your changes, and the version number updates on its own.

Keys — Stable Identifiers

Each form has a unique key — a human-readable identifier like contact-form or bug-report. Unlike internal IDs that change between environments, keys remain the same everywhere. This means a form with the key contact-form in your staging environment refers to the same form definition when promoted to production.

Keys are set when you create a form and should not be changed after the form is in use, since other parts of the system may reference them.

Draft vs. Published

Forms have two states:

Draft — The form is in development. Only team members with edit permission can see and test it. It will not appear to your audience.
Published — The form is live and active. It can be displayed to your audience and will accept submissions.

You can switch between draft and published states at any time from the form builder. Unpublishing a form immediately removes it from public view without deleting it.

Permissions

Form schemas support group-based permissions that control who can do what with each form:

Permission	What It Allows
View	See the form and its definition
Edit	Modify the form's fields, layout, and settings
Delete	Remove the form entirely
Manage	Change who has permissions on the form
List	See the form in lists and search results
Execute	Submit data to the form

Permissions are assigned to groups, so you can grant your content team edit access while giving your marketing team view-only access, for example. For public forms, anonymous visitors can view and submit the form without any account.

Combine publishing and permissions for a flexible review workflow. Keep a form in draft mode while your team collaborates on it, then publish it when it is ready for your audience.

To learn how to build and configure schemas visually, see the Builder page. For details on the input types available for your form fields, see Controls.