Dummy Field
A field that stores no data. It exists to structure or annotate the form.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
What it is for
- Section headings, breaking a long form into readable parts.
- Instructions — explaining what a section wants, where it will actually be read.
- Spacing and separation between groups of fields.
- Warnings at the point they are relevant.
Structure makes long forms usable
An unbroken run of thirty fields is exhausting to complete and easy to lose your place in. The same thirty divided into four labelled groups is a different experience, and the difference shows in completion rates and in error rates.
It is one of the cheapest improvements available on a form.
Put guidance where it is needed
Instructions in a separate document are not read. Instructions immediately above the section they concern are. Where a question is regularly misunderstood, a sentence in the right place removes the misunderstanding permanently.
It still occupies the definition
Although it holds nothing, it is a field on the datastore — it appears in the field list and adds to what somebody maintaining the model reads through.
That is a small cost and worth spending deliberately. A form with fifteen dummy fields is harder to maintain than one with four well-placed ones, and the visual benefit does not scale.
Do not use it for content that belongs elsewhere
A dummy field is not a place for policy text, long explanations or anything that changes. Content maintained here is content maintained by an architect editing a field definition.
Where guidance is substantial or changes regularly, link to it rather than embedding it.
Keep the text short
People skim forms. A paragraph above a section will be skipped; a single clear sentence will be read. If you need more than a couple of lines, the form itself probably needs simplifying.
Mind the other renderings
A record printed, exported or shown through the API will not include these — they are form furniture, not data. Do not put anything in one that somebody needs when reading the record elsewhere.
Anything that must travel with the record is a real field.
Check it on a phone
Headings and spacing that look right on a wide screen can look odd on a narrow one. Since the whole point is presentation, it is worth confirming the presentation actually works where the form is used.
Worked example
A twenty-eight-field application form is divided into four labelled sections with a dummy field heading each, plus one short instruction above the section people most often filled in wrongly. Completion improved and queries about that section stopped. No other guidance was embedded — the scheme rules are linked, because they change each year.
Recommendations
- Break long forms into labelled sections.
- Put guidance where the question is, not in a separate document.
- Keep the text to a sentence.
- Link to anything that changes rather than embedding it.