# Core Concepts Canonical: https://useformwork.com/docs/getting-started/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. ```text 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](/docs/platform/accounts-projects) and [Users & Permissions](/docs/platform/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](/docs/forms/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](/docs/forms/form-structure), then use [Field Types](/docs/forms/field-types) as the catalogue and [Field Settings](/docs/forms/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](/docs/entries/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](/docs/workflows/references) 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](/docs/data-tables/overview). ## 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](/docs/entries/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](/docs/workflows/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 - Build and publish a form with [Quick Start](/docs/getting-started/quick-start). - Learn the builder in [Form Structure](/docs/forms/form-structure). - Configure automation with [Workflow Basics](/docs/workflows/basics). - Share a form with [Sharing & Preview](/docs/forms/sharing-preview). - Embed and customise it with the [Web Component](/docs/embedding/web-component).