Validation
Validation rules let you reject submissions until the visitor enters acceptable values. Rules show inline errors under the field as the visitor types or moves on, and the Submit button stays disabled until everything passes.
There are two places validation rules come from:
- The Properties tab's type-specific options — built-in rules attached to the field's options (e.g. Number Min/Max, Text Min/Max Length, Email format, Password strength).
- The Validation tab — additional rules you add per field (e.g. a custom regex pattern with a custom error message).
Both layers are checked. If either layer flags an error, the field is invalid.
Built-In Format Validation
These rules are always active for the corresponding field type — you don't add them, they're inherent.
| Field Type | Built-In Rule |
|---|---|
email | Must match something@something.tld |
phone | Must be a valid phone number per libphonenumber-js for the chosen country |
url / website | Must parse as a URL with http:// or https:// protocol |
number | Must be numeric |
date / time / datetime | Native browser date/time validity |
The Required Toggle
Every field has a Required toggle in the Properties tab. When on, the field must have a non-empty value before submission.
For toggles and consent fields specifically, "non-empty" means 'true' (checked). An unchecked required consent blocks submission.
The Validation Tab
Click any field, then click the Validation tab. Click + Add to add a rule.
Each rule has three parts:
| Field | What It Does |
|---|---|
| Type | The kind of rule (Min Length, Max Length, Regex Pattern, Email Format, URL Format) |
| Value | The constraint (e.g. 3, ^[A-Z][a-z]+$, blank for format checks) |
| Error message (optional) | Custom message shown when the rule fails. If blank, a generic default is used. |
Add as many rules as you need. They're all checked — if any fails, the field is invalid.
Available Rule Types
| Type | Value | What It Checks |
|---|---|---|
| Min Length | Number | Character count is at least this |
| Max Length | Number | Character count is at most this |
| Regex Pattern | Regular expression string | Value matches the regex |
| Email Format | (none) | Value matches a basic email pattern |
| URL Format | (none) | Value parses as a URL |
Password-Specific Rules
The password field's strength rules (Require uppercase / lowercase / number / special) are configured in the Properties tab, not the Validation tab. They're internally translated into validation rules of types require_uppercase, require_lowercase, require_number, require_special.
How Errors Show
Errors appear inline only after the visitor has touched the field (focused and blurred) OR after they've attempted to submit. This avoids a wall of red the moment the form opens.
| Visitor Action | What Shows |
|---|---|
| Form just loaded | No errors visible |
| Visitor types in a field, then tabs out | That field's error renders |
| Visitor clicks Submit while form has errors | Every invalid field highlights, plus the field-level error renders |
| Submit button | Stays disabled the whole time the form is invalid |
Inline error messages are red and appear directly below the input.
Worked Example: Custom Regex Pattern
Goal: a Text Input that accepts only a name in Title Case (one capital letter followed by lowercase only, no spaces or digits).
Steps:
- Drop a Text Input on the canvas.
- In Properties, set Label to
Name, mark Required. - Click the Validation tab.
- Click + Add. Pick
Regex Patternfrom the dropdown. - Value:
^[A-Z][a-z]+$ - Error message:
Please enter a Title Case name (e.g. Alice). - Save.
Now alice is rejected with the custom error, Alice passes.
If you set a defaultValue on a field that violates one of its validation rules, the form will load already-invalid and the visitor has to fix it before submitting. Make sure your defaults pass.
Form-Level Submit Block
The form-level Submit button is disabled while ANY input field has an error. Hovering shows the tooltip "Please fill out all required fields before submitting". There's no way to bypass — visitors must clear every error before the form can POST.
In conversational forms, the Continue button on the current screen is disabled with the same logic, but only blocks based on the current screen's fields. Other screens' validity is checked at the final step before the actual POST.
Next Steps
- Field Properties — Built-in validation per field type
- Conditional Logic — Hide fields entirely (no validation when hidden)
- Form Settings — How required fields are marked