Use a group component when a person needs to enter the same set of fields more than once—for example, several previous addresses, multiple attendees, items in a claim, or people connected to a request. Each repeat contains the group’s nested components.

A group is a data structure as well as a page pattern. Govforms generates the group’s internal identifier; authors do not enter or reference it. Give every field inside the group a stable Field ID, because conditions, actions, templates and exports may refer to those repeated field values. The group itself is not addressed by ID in Liquid.

Start with the simplest repeat experience

The group can be displayed as boxed entries, entries separated by rules, a table, or an inline data grid.

flowchart TD
  A[Does a person need to repeat the same fields?] --> B{Are the entries complex?}
  B -- Yes --> C[Use boxed entries]
  B -- No --> D{Do people need to compare many rows?}
  D -- No --> E[Use boxed or separated entries]
  D -- Yes --> F{Are users confident with spreadsheet-style editing?}
  F -- Yes --> G[Consider a data grid with table fallback]
  F -- No --> H[Use a table]

Set meaningful entry limits

Configure the minimum and maximum number of entries. A minimum of zero makes the group optional; once the minimum is reached, a person cannot remove entries below it. Always set a real maximum that reflects the service rule and avoids an unbounded workload.

Tell people about the limit before they begin. For example: “You can add up to 10 previous addresses.” Do not rely on the interface to reveal an unexpected limit only after several entries have been completed.

Use the repeat heading to identify each entry, such as Previous address $n or Person $n. The number placeholder makes the title and remove action understandable as entries are added.

Make add, edit and remove actions clear

Customise “Add first” and “Add another” text only when a more specific action helps. Examples include “Add a previous address” and “Add another dependent”.

Every entry should be removable unless the minimum count or service rule prevents it. If removing an entry has a significant consequence, explain it near the action or in the journey design.

On a review page, provide a clear link back to add, edit or remove entries. A person must be able to correct a single entry without having to understand the group’s underlying data structure.

Sorting and read-only values

Groups can sort entries automatically by one or two nested fields. Use sorting only when the order is not a decision made by the person. For example, chronological sorting of events may be useful; sorting a person’s prioritised list may be wrong.

Choose the sort method to match the data: alphabetic, numeric or date. Test equal values, missing values and every date format that can be entered. Automatic sorting hides manual move controls, so it must reflect the intended presentation order.

You can prevent selected nested fields from being changed after a value is set. Use this only where the value genuinely should be fixed. A read-only value still needs a clear explanation and a route to correct an error if appropriate.

Tables and data grids need extra care

Tables and grids are best for short, repeated records with consistent columns. Keep headers concise, avoid dense columns, and test the component on a narrow screen and with keyboard navigation.

For a data grid:

• keep the number of editable columns small;
• use clear, visible column headings;
• choose column sizing that preserves readable headings and values;
• provide the table-view fallback unless there is a documented reason not to; and
• test calculated rows, totals and live recalculation with empty, changed and deleted rows.

Do not place long narrative text, complex conditional fields or multi-step decisions in a grid. A sequence of standard entries is usually clearer.

Test a full repeat journey

• Add the first entry, then add further entries up to the maximum.
• Remove an entry at, above and below the configured minimum.
• Check all nested validation rules in several entries.
• Edit a saved entry and return to the page.
• Test sort order, including equal and missing values where sorting is enabled.
• Check review, actions, templates and exports for more than one entry.
• Test tables and grids using keyboard navigation and a narrow display.
• Resume a draft with several entries and verify every field returns in the correct row.

Related guidance

• Shared component settings
• Text components
• Results table components
• Write Liquid templates