How to control when a field appears (conditional visibility) and what values it accepts (validation rules) in the TrustPager form builder. Covers operators, cross-field comparisons with multiplier/divisor, custom error messages, and how the two features compose.
Two features in the form builder give you precise control over what your form shows and what it accepts: conditional visibility hides or reveals a field based on what the person has already entered, and validation rules block submission when a field's value doesn't meet a requirement you define. Both are configured in the field editor panel — select any field in the builder to open it.
You'll find both features at https://app.trustpager.com/form-builder/<template-id>: select a field, then scroll the right-hand panel to Conditional visibility or Validation rule.
Conditional visibility lets you show or hide a field depending on the value of another field that appears earlier in the form. Use it to keep forms short and focused — only ask a question when the answer is actually relevant.
The field is hidden by default and only appears when the condition is met. If the field was visible and then its condition stops being true (the person changes an earlier answer), the field hides again and any value they entered is cleared.
Example: A form has a "Do you have an existing policy?" yes/no field. You add a "Policy number" text field with the condition: Do you have an existing policy? is Yes. The policy number field only appears when the person answers yes.
Validation rules apply to number and date fields. When a rule fails, submission is blocked and your custom error message appears inline next to the field. The person can't proceed until the value satisfies the rule.
Validation runs on the public form, the internal form (when you fill it yourself in the builder), and the client portal fill surface.
When comparing against another field, number fields let you optionally apply a multiplier and a divisor to the other field's value before the comparison runs. This lets you express proportional limits without needing a separate calculated field.
For example, to check that a value is at most 70% of another field divided by 12, you set the comparison target to that field, the multiplier to 0.7, and the divisor to 12. The rule then checks: this field <= other field × 0.7 ÷ 12.
For date fields, the comparison target can be a fixed date or another date field on the form. Use this to enforce ordering between dates — for example, adding a rule on an "End date" field with the operator must be after and the comparison target set to the "Start date" field. If the person enters an end date that falls before the start date, submission is blocked with your error message.
An insurance quote form needs to enforce that an income protection monthly benefit cannot exceed 70% of the applicant's monthly income. Here is how to set it up:
When someone enters a benefit that exceeds the cap, submission is blocked and they see the message inline. The calculation — annual income × 0.7 ÷ 12 — runs entirely in the form. No external system is needed to catch the error.
A field can have conditional visibility and a validation rule at the same time. The validation rule only runs when the field is visible — if the field is hidden by its conditional visibility setting, any value it holds is not validated and does not block submission.
This means you can build forms that adapt to the person's answers and still enforce the right constraints on whatever fields are actually shown.
Note: Validation rules check deterministic conditions you define — comparisons between numbers and dates. They are not a substitute for checks that depend on external data or calculations your platform needs to perform after submission. Use validation rules to guide the person filling the form; use post-submission automations for anything that requires a system lookup.
Talk to Evie right now, or book a real human for a deeper walkthrough. Whichever feels right.
Hear her in 10 seconds.

60 minutes with a real human · Google Meet · Free.