Dynamic Add/Remove
Lets a user add and remove repeated rows within a single record — several of something, without knowing how many in advance.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
What it stores
All the rows together, as text on the parent record. It does not join, and the rows are not records.
Should this be a datastore instead?
The question to ask before choosing a repeating field, and the one people wish they had asked. Repeating rows inside a field are convenient and they are not records — they cannot be reported on individually, cannot be searched as records, cannot carry their own permissions, and cannot be linked to from anywhere else.
The test: will anybody ever ask a question about the rows rather than about the parent? "How many lines mention this product", "which of these are outstanding", "show me every one across all records" — if any of those will be asked, the rows want to be a datastore of their own with a link back to the parent.
Converting later means migrating data out of a field and into records, which is real work. Deciding early costs nothing.
When the field is the right answer
- A short list belonging entirely to the parent — other names somebody is known by, a few phone numbers, previous addresses.
- Rows nobody will report on individually.
- Data that only ever makes sense in the context of the parent record.
When a datastore is
- Rows with their own lifecycle — a status, an owner, dates that change.
- Anything you will count, total or filter across records.
- Rows that other records should link to.
- Rows needing their own permissions — one row visible to more people than another.
Keep the row count small
The field is designed for a handful. Somebody adding forty rows produces a form that is slow to load, awkward to edit and unpleasant to read — and that is a strong signal it should have been a datastore.
Consider setting a maximum, both to keep the form usable and to surface the modelling question before it becomes a migration.
Validate each row
Row-level validation matters more here than on ordinary fields, because bad data is buried inside a field rather than sitting in a record where it is visible. A malformed row can go unnoticed for a long time.
Editing is all-or-nothing
Rows are part of the parent, so changing one is changing the parent record. The audit trail records the whole field before and after rather than "row three changed", which is worth knowing when trying to work out what somebody did.
Ordering
Decide whether the order means anything. If it does, make sure it is preserved and that users can reorder; if it does not, do not let people assume it does.
Worked example
A person record uses this field for previous names — usually none, occasionally two or three, never reported on separately. Their employment history is a datastore instead, because each role has dates, an employer link and a verification status, and the team reports on employers across everybody.
Recommendations
- Ask the datastore question first, before anything else.
- Keep it to a handful of rows, and cap it.
- Validate each row — bad data hides here.
- Use a datastore the moment rows need a lifecycle.