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.

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

Ensure the validator's answer type matches the target question’s type—e.g., string validators won't apply to number fields.

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)

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.

Custom code rules

For more flexibility, you can write custom validation functions using TypeScript.

Example:

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.

Note: Only the first validation error is shown—custom functions exit at the first return.

Async custom code

Enable async mode to fetch data from external sources during validation using await.

Example (hypothetical Twitter handle check):

function myFunction(value: string): Promise<ValidatorResult | undefined> { // 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'
    }
  }
}

You must enable the Async checkbox in the validator configuration.

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) has the added benefit of evaluating all rules concurrently, and outputting an error message for each rule that is violated: