FormWork FormWork

FormWork documentation

Core Concepts

A plain-language map of FormWork, from accounts and forms to entries, references, and workflows.

FormWork combines a form builder, structured data, and workflow automation. You can begin with a simple form and add the deeper features only when you need them.

The short version

  1. An account contains people, billing, API keys, and projects.
  2. A project groups forms, data tables, templates, and extensions.
  3. A form version contains pages, fields, appearance, settings, and workflows.
  4. A published version collects entries.
  5. References let logic, templates, and workflows use data from entries and tables.
Account
└── Project
    ├── Forms
    │   ├── Versions → Pages → Fields
    │   └── Entries → Answers, metafields, files, revisions, workflow runs
    ├── Data tables → Rows
    ├── Reusable templates
    └── Extensions and API Connectors

Accounts and projects

An account is the security and billing boundary. Its users have either the Admin or Standard account role. API keys also belong to an account.

A project is an organisational container inside an account. Every account member can work across the account’s projects; FormWork does not currently provide separate project membership or project-specific roles.

Projects contain four feature areas:

  • Forms collect and process submissions.
  • Data Tables hold reusable structured records.
  • Templates provide shared email and PDF content.
  • Extensions connect provider-specific features or external HTTP APIs.

Read Accounts & Projects and Users & Permissions for account operations and role boundaries.

Forms and versions

A form is the long-lived record you see in a project. Its editable content lives in form versions.

  • A draft is the editable working version.
  • A published version is the live version used by new respondents.
  • An archived version is a previous published version retained for historic entries.

Publishing promotes the draft and archives the previous published version. An in-progress entry keeps the exact version on which it began, so a later publish cannot silently change its fields or workflows.

A version contains:

  • Pages and fields
  • Field defaults, validation, and display logic
  • Workflows and triggers
  • Public title, description, submit label, and success message
  • Saved appearance and theme settings

See Form Versions for the full lifecycle.

Pages and fields

Pages divide a form into steps. Both pages and fields can have display logic.

FormWork includes 27 built-in field types:

  • Inputs such as text, number, date, choice, signature, and file fields
  • Templated fields for names and addresses
  • Groups for nested structure
  • Content fields such as headings, paragraphs, buttons, HTML, images, and video

Many answer fields can also be repeatable, creating an ordered list of instances. Field IDs are stable machine names used by answers, references, exports, and APIs; labels are the respondent-facing text and can be changed safely.

Start with Form Structure, then use Field Types as the catalogue and Field Settings for every shared and type-specific option.

Entries and answers

An entry is one instance of a respondent working through a form. Its status is:

  • Draft while it is in progress
  • Complete after a successful submission

Workflow run status is tracked separately; a failed workflow does not change an entry into an “error” entry.

Answers are stored as a flat map keyed by field path. Simple answers look like email; nested and repeated answers use paths such as address.city or line_items[item_1].quantity. You normally choose values with the reference picker rather than writing these paths yourself.

Each entry can also have:

  • Metafields for internal review data
  • Files uploaded by respondents or generated by workflows
  • Revisions recording initial submission and admin edits
  • Workflow runs with step-by-step diagnostics

Read Managing Entries for the everyday workflow.

References

A reference is a structured pointer to data. References power defaults, conditions, templates, view filters, and workflow mappings.

Common sources include:

  • The current entry and its answers
  • Entries from another form
  • Data table rows
  • The current form or version
  • Outputs from earlier workflow steps
  • The current item in a loop

The reference picker builds valid references and checks the expected value type. For advanced use, References & Data explains paths, filters, ordering, selectors, and iteration.

Data tables

A Data Table is a project-scoped, spreadsheet-like store with typed columns and rows. Use one for products, prices, territories, lookup values, or any records shared by multiple forms.

Choice fields can use table rows as dynamic options. The respondent sees the configured label; the saved value is the stable row ID. Workflows can then look up the rest of that row.

See Data Tables.

Metafields

Metafields are admin-only fields linked one-to-one with normal entries. They are ideal for internal status, ownership, review notes, or calculated operational data that respondents should not see.

Metafields have their own form version, workflows, revisions, and validation. Read Metafields.

Workflows

A workflow is a graph of triggers, steps, and connections.

  • A trigger starts a run, for example after submission, an answer update, a button click, or an API request.
  • A step performs work, such as branching, calculation, updating records, sending email, generating a PDF, or calling an extension.
  • A connection determines the next route, including success, true/false, loop, or error paths where supported.

Runs are recorded against the entry so admins can inspect inputs, outputs, duration, chosen path, and errors. Start with Workflow Basics.

Templates and extensions

Reusable templates hold project-level email or PDF content. Content templates provide the body; layout templates wrap that body using {{ content }}. Both can use merge data and FormWork references.

Extensions add provider-specific fields, actions, or webhooks. API Connectors are a special extension type for defining reusable outbound HTTP actions without executable code.

Where to go next