Visibility & requirement rules
Rules make questionnaires react to answers: show a follow-up only when it’s relevant, require a field only in some situations, skip a whole step for some respondents. Rules live on steps, tabs, and questions (sections are visual grouping only), and each carries two independent rules:
- Visibility — is this shown?
- Requirement — must this be answered? On a step or tab, a matching requirement rule makes every question inside required — the editor reminds you of that cascade when you set one.
The rule builder
Section titled “The rule builder”Every rules panel starts with a checkbox — Always visible (or Always required). Uncheck it to add conditions:
- Question — which answer to test. The dropdown lists answerable questions only; display text and file-upload questions can’t be referenced (a file’s content isn’t something a rule can compare). A question can never reference itself.
- Sub-field — appears for address targets: test
city,state,postalCode, etc. individually. Address conditions always target a sub-field, never the whole address. - Operator — filtered to what the target type supports (below).
- Value — typed to match: option labels come from a dropdown, yes/no targets offer their two labels, numbers get a number input, dates a date picker.
With two or more conditions, a Match selector chooses All conditions (AND) or Any condition (OR). There is no nesting — one flat list, one combinator. In practice this covers nearly everything; when it doesn’t, restructure with an intermediate question.
Two states are worth noticing:
- Unchecking “Always visible” with zero conditions means never shown — the builder shows a warning badge, and the structure views mark the element with a “never shown” indicator so it can’t hide silently.
- A condition referencing a question that appears later in the questionnaire is legal but flagged with a small history icon: it evaluates false until the respondent goes back and answers.
Operators by question type
Section titled “Operators by question type”| Target type | Operators |
|---|---|
| Text box, Email, Phone | equals, not equals |
| Radio, Dropdown | equals, not equals (against option labels) |
| Checkboxes | contains, does not contain |
| Number | equals, not equals, greater than, less than |
| Date | equals, not equals, before, after |
| Toggle (yes/no) | equals, not equals (true/false) |
| Address (per sub-field) | equals, not equals |
| File upload, Display text | — (cannot be referenced) |
Comparisons are exact and case-sensitive; before/after are strict
(equal dates match neither); greater/less than compare numbers, never
strings.
How unanswered questions evaluate
Section titled “How unanswered questions evaluate”This is the part worth internalizing, because it decides how your logic behaves on a half-finished form. The rule engine’s principle:
No condition is ever true against an unanswered question.
In plain words:
- equals — true only when answered with exactly that value.
- not equals — true only when answered with a different value. An unanswered question does not count as “not equal”. If you want “show unless they picked X”, remember it stays hidden until they answer at all.
- contains / does not contain — same asymmetry: does not contain is true only when they’ve selected something, just not that option.
- greater/less than, before/after — true only for an answered, valid value on the right side of the comparison.
An untouched yes/no toggle has no answer — equals false does not
match it; only an explicit “No” does. A number answer of 0 and a toggle
answer of false are answers. An address sub-field left blank counts
as unanswered.
Hidden means cleared
Section titled “Hidden means cleared”When a rule hides a question, its answer is deleted — immediately, in the live form. If hiding that answer makes another rule hide something else, the clearing cascades until the form is stable. This is what makes logic predictable: there is no such thing as a hidden answer secretly keeping some other question visible. A question that becomes visible again starts blank.
Answers cleared this way include uploaded files — the embed releases them, and the server’s cleanup job backstops any that slip through.
When rules break their references
Section titled “When rules break their references”Renaming a question code updates every condition that references it. Deleting a referenced question removes those conditions — and a rule left with zero conditions fails open (always visible / always required) rather than hiding content. In every case the editor shows you the exact impact and asks first. Details: Question codes.
Validation timing
Section titled “Validation timing”Drafts save with lenient validation — dangling references are tolerated while you’re mid-edit. Publishing validates strictly: every reference must resolve, every operator must fit its target type, every condition value must be the right kind. Publish problems are listed in full in the publish dialog, never one at a time.