# Data Tables Overview

Canonical: https://useformwork.com/docs/data-tables/overview

Store and manage structured data for forms and workflows.

Data Tables are project-level stores for structured reference and operational data. Use them for option lists, catalogues, prices, tax rates, and records that several forms or workflows need to share.

## How Data Tables Work

A data table has:

- **Columns**, which define typed cells
- **Rows**, which hold the records
- **References**, which let forms and workflows read rows and cells

Each row has a stable ID and timestamps, and can be managed through workflows or the API. This makes tables suitable for data that needs to be referenced reliably even when a displayed label changes.

The table editor is intentionally simpler than the form builder. It does not expose nested groups, repeaters, metafields, conditional field configuration, or a workflow builder.

## Create a Data Table

1. Open a project and select **Data Tables**.
2. Select **Create Table**.
3. In **Create New Data Table**, enter a name.
4. Select **Create Table**.
5. Use **Add Column** to define the table structure.

## Column Types

| Type | Use for |
|------|---------|
| Text | Names, codes, and other short text |
| Number | Prices, rates, quantities, and scores |
| Date | Calendar dates |
| Boolean | Yes/no values |
| Time | Times without a date |
| Date and time | A timestamp with date and time |
| Email | Email addresses |

When you add a column, FormWork creates its ID and type. You can rename the column later, but its ID and type remain fixed so references and existing data stay stable.

Select the table title to rename the table. Use a column header's edit action to rename that column, or its delete action to remove the column after confirmation. Column deletion removes it from the active schema and the current interface has no restore control, so review references, views, and exports first.

## Manage Rows

Add at least one column, select **Add Row**, then click a cell to edit it. Changes save automatically. The editor uses the appropriate control for each column type, including number/date/time inputs and a boolean toggle.

Keyboard shortcuts make table entry faster:

- **Tab** or **Enter** saves the current cell and moves to the next cell.
- **Shift+Tab** saves and moves to the previous cell.
- **Shift+Enter** saves and adds a row.

Delete a row from the action at the end of that row. Row deletion is individual; the table editor does not currently provide checkbox-based bulk deletion.

## Views, Imports, and Exports

Use views to save filters and choose which columns appear. Adding columns or rows is disabled while a filtered view is selected; return to **Show all rows** to change the table structure.

For bulk changes, export the table, edit it in a spreadsheet, and import it again. Import and export jobs and their files appear in the **Files** tab.

## Use a Table as an Options Source

Select, radio, and multiselect fields can load their choices from a data table. The displayed label can come from a cell such as a product name, while FormWork stores the selected row's ID as the answer value.

See [Using as Options Source](/docs/data-tables/options-source) for setup and filtering examples.

## Reference Rows in Workflows

Data table references always start with the table ID and `.rows`:

```text
data_table:<table-id>.rows
data_table:<table-id>.rows[cells.sku=ABC]
data_table:<table-id>.rows[cells.sku=ABC][0].cells.price
```

For example, if the current entry stores a selected product row ID:

```text
data_table:<products-table-id>.rows[id={entry:current.answers.product}][0].cells.price
```

Use the reference picker to insert real table, column, and field IDs. Nested references inside filters use single braces, as in the example above.

## What Tables Do and Do Not Support

Workflows can create, update, or delete rows, and API clients can manage them. The data table editor itself does not provide a workflow authoring screen.

Data tables do not support row metafields or nested column structures. For records that need respondent-facing pages, nested or repeatable fields, conditional logic, or directly configured workflows, use a regular form.

## Good Practices

- Keep each table focused on one kind of record.
- Give tables and columns clear names; use the reference picker instead of copying labels into reference strings.
- Treat row IDs as the stable identity of option values. A label can change without changing saved selections.
- Review filters before deleting rows that may already be selected by entries.