Visibility rules let you build forms that adapt as the user answers them. Instead of showing every possible question to everyone, you write a rule — and the form shows, hides, or requires questions automatically based on what the user has answered.
Rules are authored in the form builder at https://input.ziplineos.com.au, on each field's card. You can add as many rules to a single field as you need.
For the settings that appear on every question regardless of rules, see Question Settings: Labels, Help, Required & AI Extract. For how answered values are validated, see Validations. For how questions are presented visually, see Display Modes.
How a rule is structured
Every visibility rule has two parts:
- An action — what happens when the rule's condition is met.
- A condition group — the set of tests that must be satisfied for the action to fire.
If the condition group evaluates to true, the action applies to the field. If it evaluates to false, the field behaves as it normally would (visible and not required, by default).
Actions
There are three actions:
| Action | What it does |
|---|---|
| Show | The field is hidden by default and revealed only when the condition is true. |
| Hide | The field is shown by default and hidden when the condition is true. |
| Require | The field becomes required when the condition is true, even if it is not marked Required in the field settings. |
A required field that is hidden by a rule is skipped by the form — the user is never asked to fill in a question they cannot see. If you use Show and Require together on the same field, the field is only required while it is visible.
Condition sources
A condition compares a value from a source against a target using an operator. Choose the source in the form builder:
| Source | What you can test |
|---|---|
| This Form | Any other answer on the same form — the most common source. |
| Other Form | An answer from a different form on the same deal. |
| Applicant | The applicant's role (e.g. Primary, Co-Borrower), their index in a multi-applicant deal, or the total count of applicants. |
| Deal | The deal's current step, its status, a specific deal-level value, or the deal's age in days. |
| Deal Owner | The broker or owner assigned to the deal — their name, role, department, or whether their account is active. |
| Other Item | Whether another workflow item (a task, a checklist, a form) has been completed or skipped. |
| System | Today's date, the current user's role, or whether the user is external (an applicant on Collect rather than a broker on Input Hub). |
| Aggregate | A computed value over a set of form fields — COUNT, SUM, MIN, MAX, AVG, date span, or days since a date. Use this to count how many instances of a repeatable sub-form have been added, or to sum the incomes across all applicants. |
Operators
Operators depend on the data type of the source value, so the list changes with the source — only comparisons that fit are offered:
| Operator | Works on |
|---|---|
| equals | Text, number, dropdown, checkbox, date |
| does not equal | Text, number, dropdown, checkbox, date |
| contains | Text (substring match) |
| does not contain | Text |
| is greater than | Number, money |
| is less than | Number, money |
| is at least | Number, money |
| is at most | Number, money |
| is empty | Any field — true when nothing has been entered yet |
| is not empty | Any field — true once any value is present |
| is earlier than | Date, date & time — supports an offset (e.g. "3 years ago") |
| is later than | Date, date & time — supports an offset |
| is on or before | Date, date & time — inclusive version of "is earlier than" |
| is on or after | Date, date & time — inclusive version of "is later than" |
Date operators accept an offset so you can write conditions like "date of birth is earlier than 18 years ago" (meaning the applicant is over 18) without hard-coding a specific calendar date.
Combining conditions
A condition group can hold multiple conditions combined with AND (every condition must be true) or OR (at least one must be true). You can also nest groups — an AND group can contain a nested OR sub-group — to express logic like "residency is Temporary visa AND (visa subclass is 457 OR 482)."
Simpler rules are easier to maintain. If logic is getting complex, consider whether an earlier conditional field can reduce the branching.
Broken rules
If a rule references a form or field that has since been deleted, the builder shows a "Broken rule" warning on the field card. The form still works — the broken condition is skipped at runtime — but the intended logic is no longer running and should be repaired or removed.
Worked example
Goal: show a "Visa details" question only when the applicant selects "Temporary visa" as their residency status.
- Add a Dropdown field labelled "Residency status" with options: Citizen, Permanent Resident, Temporary visa.
- Add a Short Text field labelled "Visa details."
- On "Visa details," add a visibility rule: Action = Show, Source = This Form → Residency status, Operator = equals, Value = Temporary visa.
The "Visa details" field is now hidden by default and appears the moment the applicant selects "Temporary visa." If they change their answer, the field disappears and any value they entered is discarded.
To make it mandatory while visible, either add a second rule with Action = Require and the same condition, or turn on the Required toggle — because the field is only shown when the condition is met, the form engine only enforces it while it is visible.
You can use Aggregate conditions to drive rules based on counts. For example, show an "Additional guarantor" section only when the Aggregate COUNT of "Guarantors" sub-form instances equals zero — prompting the broker to add at least one before the field disappears.
Things to keep in mind
- Preview ignores cross-form conditions. The builder's preview has no deal context, so conditions that reference Other Form, Deal, or System sources may not behave as expected. Test them on a real deal.
- Order matters for Show rules. Put the source question before any field that depends on it — a hidden field won't appear until the condition is met, regardless of its position in the list.
- Deleting a source field breaks dependent rules. Before removing a field, check whether any rules reference it. A "Broken rule" warning will appear on any affected field.