# Forms with nested repeatable data

Canonical: https://useformwork.com/product/nested-data

Updated: 2026-09-17

Model several people, companies, items, or addresses in one form while keeping each repeated instance identifiable.

FormWork supports repeatable field groups, including groups nested inside other groups. Use them when a respondent needs to enter an unknown number of related items, rather than squeezing each item into a fixed set of numbered fields.

## Example: companies and their contacts

A client onboarding form might collect several companies, each with several contacts:

- A company group contains the company name and registration details.
- Inside each company, a repeatable contact group contains a person's name and contact details.
- Respondents add the number of companies and contacts they need.

This is an implementation pattern, not a claim that a complete onboarding application is included. You still configure the fields, validation, and subsequent review process.

## Stable identity matters when items move

Repeated instances have stable IDs. Reordering an item changes its position without making it a different item. This is useful when calculations, workflow steps, or a custom interface need to refer to the same instance after a respondent edits a list.

The API represents answers as a flat map of paths to primitive JSON values. A repeated field can have a path such as:

```text
line_items[item_a].quantity
```

The repeated group stores the ordered instance IDs. Nested paths identify the hierarchy without requiring a different database column for every possible item. Follow the exact answer format in the [form structure documentation](/docs/forms/form-structure) and [API reference](/docs/api/reference).

## Working with the results

Use [For Each workflow steps](/docs/workflows/for-each) to process repeated data, [templates](/docs/templates/syntax) to render it, and [entry administration](/docs/entries/managing-entries) to inspect submissions. Conditions and validation still need to be designed for the repeated structure.

Field IDs become part of answer paths. Choose them carefully: the builder does not let you change a field's ID or type after creation. Publish structural changes through [form versions](/product/versioned-forms), and test integrations against representative nested answers.

See the [data modelling article](/blog/how-we-model-complex-repeatable-data-in-forms-without-losing-our-minds) for the design rationale, or [client onboarding](/use-cases/client-onboarding) for a practical walkthrough.