# Field validation Field validation ensures that the data collected in your flows meets defined formatting, business, and quality requirements. Formsort supports both built-in and custom validators. *** ### Built-in Validators Formsort includes many default validators for common input types: * **Number questions**: Enforce min/max value, integer constraints, and step intervals. * **Email fields**: Automatically validate email formatting. * **Text fields**: Can be configured with length or character restrictions. These default validators cover the most common cases. For advanced use cases, **custom validators** are available. *** ### Custom Validators (Enterprise Only) Custom validators allow you to define your own validation logic using regular expressions, custom code, or asynchronous API calls. They are defined at the **workspace** level and can be reused across flows.

Custom validators are defined at the workspace level

### Defining Custom Validators Custom validators are composed of two main parts: #### **1. Validator Metadata** Metadata includes: * **Name** and **description** (used for identification in the Studio) * **Answer type** (e.g., string, number, object) – this controls which questions or variables can use the validator

{% hint style="info" %} Ensure the validator's answer type matches the target question’s type—e.g., string validators won't apply to number fields. {% endhint %} #### **2. Validation Rules** Validators can contain multiple rules. Each rule must pass for the value to be considered valid.

#### **Rule Severity** * **Error**: Blocking. The responder cannot proceed unless the input is corrected.

* **Warning**: Non-blocking. The responder is alerted, but may choose to proceed.

### Regular expression rules Regular expressions (`regex`) are available only for string inputs. You can create rules for inputs that **must match** or **must not match** a given pattern. **Example: Twitter Handle Validator** | Rule Type | Pattern | Error Message | | ------------------ | ----------------- | ------------------------------------------------------------------------------- | | **Must match** | `^[a-zA-Z0-9_]+$` | A username can only contain alphanumeric characters (A–Z, 0–9) and underscores. | | **Must match** | `^.{1,15}$` | Handles must be between 1 and 15 characters long. | | **Must not match** | \`Twitter | Admin\` (case-insensitive) | {% hint style="info" %} Rules 1 and 2 (and probably 3) can be collapsed into a single regular expression that checks for both, which would be `^[a-zA-Z0-9_]{1,15}$.` Splitting out rules is preferred, as it allows for more targeted error messages. We can warn users with a specific message when they have an invalid character OR their handle is too long, making it easier to see what's wrong with the input and correct it. {% endhint %}

### Custom code rules For more flexibility, you can write custom validation functions using TypeScript. **Example:** ```typescript function myFunction(value: string): ValidatorResult | undefined { // readonly line if (value.match(/admin|twitter/i)) { return { severity: 'error', message: 'Handle cannot contain the words "admin" or "twitter"' } } if (value.match(/[^a-zA-Z0-9_]/)) { return { severity: 'error', message: 'A username can only contain alphanumeric characters (letters A-Z, numbers 0-9) with the exception of underscores.' } } if (value.length > 15) { return { severity: 'error', message: 'Usernames cannot be more than 15 characters long' } } } ```

* Return a `ValidatorResult` when the input is invalid. * Return `undefined` when input passes validation. {% hint style="info" %} Note: Only the first validation error is shown—custom functions exit at the first `return`. {% endhint %} ### Async custom code Enable **async** mode to fetch data from external sources during validation using `await`. **Example (hypothetical Twitter handle check):** ```typescript function myFunction(value: string): Promise { // readonly line const res = await fetch('https://api.twitter.com/check-handle'); const handleInfo = await res.json(); if (handleInfo.taken) { return { severity: 'error', message: 'This handle has already been registered' } } } ``` {% hint style="info" %} You must enable the **Async** checkbox in the validator configuration. {% endhint %} ### Testing validators Use the **Test** tab to try out inputs and preview validation behavior: * **Regex rules**: All rules are evaluated in parallel. Violations for each rule are shown independently. * **Custom functions**: Only the first failed check is returned. **Examples:**

Using the Regular Experssion UI (described [above](#regular-expression-rules)) has the added benefit of evaluating all rules concurrently, and outputting an error message for each rule that is violated:

*** ### Using custom validators in a flow Once created, custom validators become selectable in Question settings (if the question’s data type matches the validator).

Picking a validator within the content editor

*** ### Updating custom validators You can modify validators at any time. However: * **Flows using the validator need to be redeployed to pick up changes.** * Use the **Show usages** option to view which flows depend on a validator.

### Deleting Validators Custom validators can be deleted from the validator list. * **Flows already using the validator will continue to function.** * Deleted validators will no longer be available to assign to new questions or answers.