Conditional Forms

Conditional Forms

A conditional form shows and hides fields depending on what has been answered so far.

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

Why it matters

A form with sixty fields, of which any one person needs twelve, is a form people abandon. The same form showing only the twelve relevant to them is one they complete.

Conditional logic is the single most effective thing you can do to a long form.

Ask the deciding question first

The question that determines what else appears should be near the top. A form that reveals half of itself after question forty has already lost the people who were counting.

Hide, do not disable

A greyed-out field is a field somebody wonders about. A hidden one is simply not part of their form, which is the experience you want.

Hiding is not security

The important caution. A hidden field is hidden in the interface; it is not protected. If a value must not be seen or set by somebody, that is field security, not a display rule.

Decide what happens to hidden answers

Somebody answers a question, changes an earlier answer, and the first question disappears. Is the answer kept or cleared?

Both are defensible and the wrong one is confusing — either an answer reappears unexpectedly, or work is silently lost. Decide, and be consistent.

Keep the rules few

Conditional logic compounds. Three simple rules are comprehensible; fifteen interacting ones produce a form whose behaviour nobody can predict, including whoever wrote them.

If a form needs that many, it is probably several forms.

Rules live with the form

Each conditional form holds its own definition, so the logic travels with the form rather than being configured elsewhere. That is good for maintenance and means the form is the place to look when behaviour surprises you.

Test every path

Each combination of the deciding answers, end to end. The untested path is the one somebody takes on the first day.

Worked example

An application form asks the applicant type as its second question and shows one of three field sets accordingly. Sixty fields became an average of eighteen per applicant, and the completion rate rose substantially. Three rules cover the whole form.

Recommendations

• Ask the deciding question early.
• Hide rather than disable.
• Never treat hiding as security.
• Test every combination of deciding answers.

Show and Hide Rules

A rule says which field appears, and under what condition.

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

One condition per rule where you can

A rule testing three things is a rule that is hard to reason about when a field does not appear. Simple rules are easier to write, easier to read and much easier to debug.

Drive from a controlled field

A rule based on a list of defined options behaves predictably. One based on free text does not — a rule matching "Yes" fails on "yes", "Y" and "yes ".

If a field drives conditional logic, it should be a constrained choice.

Avoid chains

A field shown by a rule that depends on a field shown by another rule is a chain, and chains break in ways that are difficult to trace. Two levels is manageable; four is not.

Beware circular logic

Field A shown when B is answered, B shown when A is answered. Neither ever appears, and nothing tells you why.

Drawing the rules out on paper finds this in a minute; reading them does not.

Group rather than rule where you can

Showing a whole section on one condition is clearer than ten rules showing ten fields on the same condition — and when the condition changes, it is one edit.

Consider what a hidden required field does

A field that is required and hidden will either block submission invisibly or be skipped. Which one it does is a thing to establish before the form is live rather than after somebody cannot submit.

Write the rules down

In plain sentences, alongside the form. "If applicant type is Business, show the company section" is documentation the next person can check the configuration against.

Test by taking every path

Complete the form once per combination of deciding answers, and submit each. Reading the rules tells you what you meant; submitting tells you what happens.

Watch for rules left after a change

When a field is removed or an option renamed, rules referring to it remain. A rule matching an option that no longer exists never fires, and the field it controls never appears.

Worked example

A form uses three rules, each on a single constrained field, each showing a whole section. When an option was renamed, one section stopped appearing; the written rules made the cause obvious within a minute.

Recommendations

• Drive rules from constrained choices, never free text.
• Show sections rather than individual fields.
• Avoid chains and check for circularity.
• Re-check rules whenever a field or option changes.

Conditional Requirements

A field can be required only in the circumstances where it applies.

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

Why it is necessary

A field required for one kind of applicant and irrelevant to another cannot be simply mandatory. Making it always required blocks people who cannot answer it; making it never required means it is missing where it matters.

Match the requirement to the visibility

The rule that avoids most problems. A field should be required exactly when it is shown. A hidden required field is a form somebody cannot submit and cannot see why.

That is the single most common conditional-form fault, and it presents as "the submit button does nothing".

Check what happens on hide

If a field is answered, then hidden by a change to an earlier answer, is its requirement still enforced? Establish this by testing rather than by assuming, because both behaviours exist in the wild.

Say why it is required

A field that becomes mandatory because of an earlier answer surprises people. A short line of help — "required because you selected Business" — removes the confusion entirely.

Do not require everything

The temptation once conditional requirements are available. Every mandatory field is a reason to abandon the form, and a proportion of them are fields somebody genuinely cannot answer.

Require what you cannot proceed without. Ask for the rest without insisting.

Validation messages must name the field

"Please complete all required fields" on a long conditional form is useless. The message should name the field and, ideally, scroll to it.

Watch the interaction with saving

If a form can be saved part way, requirements should apply at submission rather than at save. A user who cannot save a draft because of a field they intend to answer tomorrow will not come back.

Test the awkward path

Answer, reveal a required field, go back, change the earlier answer, and submit. That sequence finds nearly every conditional-requirement fault.

Worked example

A form makes company details required only for business applicants, with help text explaining why, and applies requirements at submission rather than at save. Testing the change-your-mind path found a hidden field still blocking submission, which was fixed before launch.

Recommendations

• Required exactly when shown, never when hidden.
• Explain why a field became required.
• Name the field in validation messages.
• Test the change-your-mind path.