Loading

Validation Rules

Every field on every form runs through validation before the underlying row is saved. ActiveManage validates client-side (for instant feedback as the user types) and again server-side (to catch anything the client-side validation might have missed or that a malicious user might have bypassed). Without validation, your datastores fill up with bad data and the consequences ripple out to every downstream use.

Built-in rules

The platform ships with sensible rules for common patterns:

  • Email format — rejects strings that aren't valid email addresses.
  • URL — rejects strings that aren't valid URLs.
  • Postcode — rejects invalid UK postcodes; other country formats configurable.
  • Regex match — rejects strings that don't match a custom pattern.
  • Numeric range — rejects numbers outside a min/max bound.
  • Length range — rejects strings shorter than a min or longer than a max.
  • Date range — rejects dates outside a from/to bound.
  • File size — rejects file uploads above a maximum byte size.
  • File MIME type — rejects file uploads whose MIME type isn't in a list.
  • Required — rejects empty submissions.
  • Unique — rejects values that already exist on another row in the same column.

Each field has a Validation setting where you pick which rule (or rules) apply. Validation runs in addition to type-level constraints (a Number field implicitly validates that the input is a number; a Date field implicitly validates that it's a parseable date).

Custom rules

For business-specific validation (e.g. "VAT number must match the customer's country"), add a custom rule to the Validations admin. Each rule is a PHP callback that receives the value (and optionally the rest of the row's data) and returns true to accept or a string error message to reject.

Examples of custom rules that come up:

Example 1: Domain restriction on email

For a B2B app where only corporate emails are accepted: a custom rule that rejects gmail.com, hotmail.com, yahoo.com etc. Implementation: PHP callback checks the email's domain against a blacklist.

Example 2: Business-day-only dates

For a date field that should only accept Mon-Fri: a custom rule that takes the date and rejects if it falls on a Saturday or Sunday.

Example 3: Cross-field consistency

"End date must be after start date" — a rule that fires on the end-date field, looks at the start-date field on the same row, and rejects if end is before start.

Required fields

The Required flag on a field is its own validation rule. It only fires when the field is visible — conditionally-hidden fields can be Required without triggering on submission while they're hidden. That's the correct behaviour because users can't fill in fields they can't see.

Where validation errors appear

Inline, immediately next to the field with the error. The error message comes from the validation rule itself ("Please enter a valid email address" or "This field is required"). The user can't submit the form until every error clears — the submit button stays disabled or returns to the form with errors shown.

Server-side enforcement

Crucially, validation runs server-side too. If a client-side check is bypassed (a curl call directly to the API, a malicious user disabling JavaScript), the same rules fire at save time. If anything fails server-side the row isn't saved and the user gets an error message.

This is why custom validation should always be implementable in PHP — client-side-only validation isn't safe. The platform's built-in rules all have server-side equivalents.

Note: Validation rules attached to a field apply across every place the field is used — the auto-generated form, Custom Forms, User Input Views, the API. There's one source of truth (the field's Validation setting); everything else respects it.