Common mistakes

The most frequent issues when building a form. The Checklist tab catches most of them.

1. Empty form (no field blocks)

A form with only sections, headings, or text and no actual field blocks saves nothing. Looks fine in the builder; produces no data.

2. A required field hidden from the form

The table marks a field Required, but the form doesn't include it. Result: every save fails with a generic "field is required" error and the user can't fix it because the field isn't visible.

Either drop the Required flag on the table or add the field block to the form.

3. Read-only fields on the create form

Read-only on Create means the user can't fill it in and it has no default. Result: a blank field that saves blank.

Read-only is useful on Edit (don't let approvers change the IC number). On Create, drop the field instead, or set a Default on the table.

4. One section per field

Sections are for grouping — five sections each containing one field is worse than no sections at all. Either merge sections or remove them.

5. Help text on every field

When help text is everywhere, users tune it out. Reserve it for the 1-3 inputs most likely to confuse — codes, IC numbers, fields with non-obvious format.

6. Forgetting to update Edit when you change Create

You add a Notes field to the Create form for v1 but forget the Edit form. Now users can add notes but never change them.

When you add or remove a field block, repeat the change on all three modes (Create / Edit / Show) before publishing.

7. Fields out of order vs the table

The form order is independent of the table's field order — that's the point — but they should mostly agree. If your table puts dates before the reason and your form puts reason first, switching back and forth between table and form gets confusing.

When in doubt, follow the data-flow order: identity (name) → classification (type/category) → details (dates, amount) → free text (reason, notes) → attachments.

When in doubt

Open the Checklist tab in this drawer.