Loading

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.