Dynamic Add Fields

What They Are

A dynamic add field lets somebody add another copy of a group of fields — another contact, another item, another qualification.

Where to find it

Architect Panel → Forms:

• Dynamic Add Fields — the definitions, then View Fields on a row
• Conditional Forms — show and hide rules
• Line Item Builders — the builders, then View Line Fields on a row

What a definition holds

A name, the text and styling of the button that adds another, and whether field titles are shown on each repeat. The fields themselves are separate rows naming the field, its order, any styling and which row it sits on.

Fields are managed through View Fields on the definition’s row.

When repetition is right

• The number of entries is genuinely unknown — one contact or five.
• Each entry has the same shape.
• Entries are equal rather than ordered or dependent.

When it is not

If entries need their own history, permissions, workflow or reporting, they are records rather than repeated fields. A related datastore gives you all of that; a repeating group does not.

The question: would anybody ever want to search across just these entries? If yes, they should be records.

Do not use it to avoid designing

Three fields with different meanings crammed into one repeating group because it was quicker is a form that is harder to complete and data that is harder to use.

Show field titles on the first, not on every repeat

A setting worth thinking about. Repeating the labels on every entry is clear and produces a very long form; showing them once is compact and can leave somebody guessing on the eighth entry.

For two or three fields, once is usually right. For more, repeat them.

The button text matters

"Add" tells nobody what they are adding. "Add another contact" does, and it also implies what the group is for, which reduces the number of people who put the wrong thing in it.

Set a sensible starting state

One empty entry is usually right — it shows what is being asked without implying more is required. Starting with none means somebody has to discover the button.

Think about removal

People add entries by mistake. Being able to remove one, clearly, matters as much as being able to add it, and an entry that cannot be removed is one that gets submitted empty.

Worked example

An application form asks for previous addresses using a repeating group of four fields, with titles shown once, a button reading "Add another address", and one empty entry to start. Applicants add between one and five, and the average number completed rose after the button was renamed.

Recommendations

• Use records if entries need history, permissions or reporting.
• Name the button after what is being added.
• Start with one empty entry.
• Repeat titles once a group has more than three fields.

Configuring One

Configuration is a definition and a list of fields, arranged into rows.

Where to find it

Architect Panel → Forms:

• Dynamic Add Fields — the definitions, then View Fields on a row
• Conditional Forms — show and hide rules
• Line Item Builders — the builders, then View Line Fields on a row

Choose the fields carefully

Every field is asked once per entry. A group of eight fields repeated four times is thirty-two answers, and somebody has to give all of them.

Ask what genuinely differs per entry, and put anything common outside the group.

Arrange across rows

Each field names the row it sits on, so related fields sit side by side rather than stacking. A first and last name on one row reads as one thing; on two rows it reads as two questions.

Order deliberately

The order within a row and the order of rows both matter. Follow the order somebody would naturally give the information — name, then role, then contact details.

Use styling sparingly

Fields can carry their own styling. Use it for width and alignment, not for decoration — a repeating group with five different visual treatments is harder to read than one that is plain.

Test on a phone

Repeating groups are where forms break on small screens. Two fields side by side become two rows, the group becomes very tall, and the add button ends up a long way from what it adds.

Test with several entries

Not one. Add five, and look at the form. That is when a group that seemed fine becomes an unusable wall, and when the button position stops making sense.

Test removing the middle one

Add three, remove the second, and check the remaining data is right. That is where repeating groups go wrong, and it is not something a user will report clearly — they will say the form "lost" their information.

Check what is stored

Complete the form with several entries and look at the resulting record. The point is not that the form worked but that the data is usable afterwards.

Consider the maximum

Somebody will add forty. Decide whether that is acceptable, and whether the form and whatever consumes the data can handle it.

Worked example

A group of four fields was arranged across two rows, tested on a phone with five entries, and tested by removing the middle entry — which revealed the remaining entries renumbering in a way that confused the downstream process. It was fixed before the form went live.

Recommendations

• Only fields that differ per entry.
• Arrange across rows so related fields sit together.
• Test with five entries, and remove the middle one.
• Look at the stored data, not just the form.