Datasets

Reference tables that supply a field's options — a price list, a branch directory, a product catalogue. Maintained in one place, published like a form, and used by any number of forms without copying the list into each.

Creating and publishing

Under Datasets (dataset:read to view, dataset:write to edit), create a dataset, then either type rows into the grid or import a CSV. The header row becomes your columns.

Datasets are versioned exactly like forms: you edit a draft and publish it. A form field bound to a dataset offers nothing until that dataset has a published version — the editor warns you when you bind to one that has never been published.

Publishing takes effect immediately on every live form using the dataset. This is the point: correct a price in one place and every form that offers it is correct from the next page load. It is also the thing to be careful about — there is no per-form pinning of a dataset version.

Importing a CSV

Import replaces the draft's columns and rows; it is not a merge. Quoted fields, embedded commas and doubled quotes are handled, values are trimmed, blank lines are skipped, and a blank header becomes “Column 2”. Importing does not publish — review the draft and publish when it looks right.

A dataset holds at most 50,000 rows. Values are stored as text; a dataset has no column types.

Binding a field to a dataset

In the form builder, add a combobox field and open its dataset binding: choose the dataset, then the column whose values become the options. Any fixed options on the field are set aside while a dataset is bound, and come back if you unbind it.

Options are served distinct, non-empty and sorted alphabetically — the dataset's own row order is not preserved, and duplicate values collapse to one. Name your values so alphabetical order reads sensibly.

Cascading dropdowns

A field can filter its options by what was chosen in another field — country then city, category then product. In the binding, set the filter field to the slug of the field supplying the value, and the filter column to the dataset column it should be matched against.

Always set the filter column explicitly. Left empty, the platform falls back to matching against a column named after the other field's slug — which works only if they happen to be identical, and generated slugs never are. The dependent field stays disabled with "Choose the previous field first" until its parent has a value.

Matching is exact and case-sensitive, so the values in the two columns must agree exactly.

Choices are enforced, not merely offered

When a submission is saved, values on dataset-backed fields are re-checked on the server against the same filtered lookup the form used. A value that is not among the available options is refused — "'City' is not one of the available options" — so a hand-crafted request cannot store a product that is not in your catalogue.

The one deliberate exception: if the dataset has been unpublished or removed, the check is skipped rather than blocking a form nobody can currently fix.

Archiving

Archiving (dataset:delete, held only by administrators unless you grant it) keeps published versions and stops the dataset being offered. Check which forms bind to it first: a bound field whose dataset is gone offers no options, and submitters simply cannot choose anything.

Datasets are not submissions

A dataset is reference data you maintain, not data people submit. There is no CSV export for datasets, no per-row permissions, and no history beyond versions. If you need to collect and work rows, that is a form — see working with submissions.