Workflow items can carry rules just like form fields can. A rule tells the platform whether to show an item, skip it, require it, hide it, or treat it as valid — all driven by live data on the deal rather than a manual decision. This lets you build adaptive workflows where items appear only for the deals that need them.
Item rules are authored in the workflow builder at https://input.ziplineos.com.au. You add them per item on its configuration panel. The same underlying condition model is used for field visibility rules, so if you have already worked with those, item rules will feel immediately familiar.
Rule types
An item can carry up to five rule sections. Which ones are available depends on the item type:
| Rule | What it does |
|---|---|
| Show when | The item is hidden by default and only appears when the condition is true. |
| Hide when | The item is visible by default and disappears when the condition is true. |
| Require when | The item becomes required (must be completed before the deal leaves the step) only when the condition is true. |
| Skip when | The item is automatically marked as skipped when the condition is true — no user action needed. |
| Validate when | The item is only considered valid (for exit or ValidationGate purposes) when the condition is true. Use this when the definition of "done" is conditional rather than absolute. |
A required item that is hidden by a rule — or skipped by a Skip when rule — is automatically exempted from exit validation. The deal will not be held up by an item the workflow itself decided to hide or skip.
Condition sources
A condition tests a value from a source against a target using an operator. Item rules use the same sources as field visibility rules:
| Source | What you can test |
|---|---|
| This Form | Any answer on a form associated with this item. |
| Other Form | An answer from a different form on the same deal. |
| Applicant | The applicant's role, 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 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, or AVG. Use this to count how many instances of a repeatable sub-form have been added, or to sum incomes across applicants. |
Operators
Operators follow the data type of the value being tested:
| 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 — true when nothing has been entered yet |
| is not empty | Any — true once any value is present |
| is earlier than | Date, date & time — supports a time offset (e.g. "3 years ago") |
| is later than | Date, date & time — supports a time offset |
| is on or before | Date, date & time — inclusive |
| is on or after | Date, date & time — inclusive |
Date operators accept an offset so you can express conditions like "settlement date is earlier than 30 days from today" without hard-coding a calendar date.
Combining conditions
Inside a rule, you can add multiple conditions and combine them 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 "loan type is Investment AND (purpose is Purchase OR purpose is Refinance)."
Keep condition logic as simple as you can. If a rule is getting complex, consider whether a form field earlier in the workflow can reduce the branching.
Worked example
Goal: automatically skip the "Guarantor pack" item when there are no guarantors on the deal.
- On the "Guarantor pack" item (a Form or Signing Package), open the Skip when rule section.
- Add a condition: Source = Aggregate → COUNT of "Guarantors" sub-form instances, Operator = equals, Value = 0.
- Save.
When the deal has no guarantor sub-form entries, the item is skipped automatically. The deal can exit the step without anyone touching the item, and the skip is recorded so you can see it in the deal's history.
For the inverse — showing the item only when guarantors exist — use a Show when rule with the same condition but is at least 1 instead.
Validate when
Validate when is the most advanced rule type. It does not hide or skip the item — it changes what counts as a passing state. If the condition is true and the item's normal completion criteria have been met, the item is valid. If the condition is false, the item is treated as valid unconditionally (it does not need to be acted on).
This is most useful with ValidationGate items. You can configure a gate to check "Insurance confirmation" only when the loan type is "Construction" — in all other cases, the gate passes that check without requiring the item to be complete.
Broken rules
If a rule references a form, field, or item that has since been deleted, the builder shows a warning on the affected item. The workflow continues to run — the broken condition is skipped at runtime — but the intended logic is no longer in effect and should be repaired or removed.
See also
- Show, Hide & Require Questions with Rules — the same condition model applied to individual form fields rather than whole items.
- Reactions: Item Automations — trigger automatic actions (emails, deal updates) when an item reaches a lifecycle event.