Configure Input-level Validators

Overview

Validators are fields that can be referenced during checks to confirm if answers are acceptable.

Input-level validators check what a user has entered in a field and block the form from progressing if the value doesn't meet the rule you've defined. They run when the user attempts to move to the next page or submit the form, and display a custom error message when the check fails.

Each field can have one or more validators, and each validator can have its own error message. Validators are configured in the Validation tab of any Edit question in the Form Designer.

‍

Use cases

Email address format

You want to confirm that what the user entered looks like a valid email address before it's submitted — catching typos like name@domain (missing the top-level domain) or name.domain.com (missing the @).

Validator to use: e-mail — checks the format automatically using a built-in pattern.

‍

Numbers only

A field like account number, Australian postcode, or phone number should only contain digits. You want to reject any input that includes letters or special characters.

Validator to use: numeric — fails if the value contains any non-numeric characters.

‍

Minimum or maximum character count

A reference number must be exactly 8 characters. A short description must be at least 20 characters but no more than 200. You want to enforce those length boundaries.

Validator to use: text — lets you set a minimum length, maximum length, or both.

‍

Specific format (phone number, postcode, date)

A phone number field should match a known pattern — for example, a 10-digit Australian mobile starting with 04. An Australian postcode should be exactly 4 digits. A custom date field should follow a DD/MM/YYYY format.

Validator to use: regex — validate against a regular expression you define, giving you full control over the accepted format.

‍

Cross-field validation (confirm email)

You have an Email field and a Confirm email field. You want to check that both fields contain the same value before the user can proceed — and show an error on the confirmation field if they don't match.

Validator to use: expression — evaluates a logic expression that can reference other fields in the form. For example: {email} == {confirmemail}.

‍

Validator types reference

Type	What it validates	Configuration
e-mail	Checks that the value is a correctly formatted email address.	No additional configuration needed — the format check is built in.
numeric	Checks that the value contains only numbers.	Set min and max numeric values if you want to limit the range as well as the format.
text	Checks that the value meets a minimum or maximum character length.	Set a Min length, Max length, or both.
regex	Checks that the value matches a regular expression pattern you define.	Enter the regex pattern. Test it against real-world input before publishing — edge cases in regex can silently block valid entries.
expression	Evaluates a custom logic expression that can reference other fields in the form.	Reference other fields by their name in curly braces, e.g. `{fieldname}`.

‍

How to add a validator

Open the form template and go to the Template tab, then select Form Designer.
Click Edit on the field you want to validate.
Click the Validation tab in the field editor.
In the Required error text field, enter the message shown when a mandatory field is left blank — for example, "Please enter your email address."
Under Validators, click the + symbol and select the validator type from the dropdown.
Configure the validator — enter a regex pattern, set length limits, or build an expression depending on the type selected.
Enter a custom error message for this validator — this is what the user sees when their input fails the check. Be specific: "Please enter a valid 10-digit mobile number" is more helpful than "Invalid input."
Click OK, then click Save in the Form Designer.

‍You can add more than one validator to a field: Each validator runs independently. A field can have both a numeric validator and a text validator at the same time — for example, to check that a value is numeric and exactly 4 characters long. Each validator can have its own error message so users know exactly what's wrong.

‍

‍Test every validator before publishing: Use Test Form to enter values that should pass and values that should fail. Confirm the right error message appears and that valid input isn't accidentally blocked — particularly for regex validators, where edge cases are easy to miss.

‍

Well-configured validators catch errors at the point of entry — before bad data reaches your systems. Keep error messages specific, test every rule against real-world input, and only apply validators where they genuinely add value. A form that rejects valid input because the regex was too strict is worse than no validation at all.

‍