> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/guides-enrolment/enrolment/enrolment-form/validation-rules.md).
# Validation rules
Validation rules protect data quality at the point of capture. They prevent incomplete or incorrectly formatted values from entering customer profiles and downstream systems.
Choose rules based on the purpose of each field. Strict validation is useful for identifiers. Optional enrichment fields should remain easy to complete.
Real-world examples
* A loyalty programme requires an email address and verifies its format before enrolment.
* A ticketing form limits a booking reference to the expected character length.
* A membership form compares the confirmation email against the original email field.
### How validation works
Validation is configured at the individual field level. Each rule checks whether a value meets the data requirements before the form is submitted.
Use a small number of rules that match the field’s purpose. Overly restrictive forms can increase abandonment and create support work.
### Available validation rules
#### Required
* Indicates whether the field must be filled out.
* For checkboxes and switchboxes, this means the box must be checked.
#### `minLength`
* Defines the **minimum number of characters** required for a field's value.
* Useful for fields like names or identification numbers.
#### `maxLength`
* Sets the **maximum number of characters** allowed in the field.
* Helps prevent excessively long inputs that could disrupt layout or storage.
#### `email`
* Combines two layers of validation:
1. **Regular Expression Check**: Uses the following default regex to validate format:
```js
/^[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?$/
```
This regex can be **overridden** with a custom one if needed.
2. **Domain Check via DNS**: The Wallet Crew verifies that the email domain accepts mail by checking for **MX records**.
#### `phone`
* Validates phone numbers using the [react-phone-number-input](https://catamphetamine.gitlab.io/react-phone-number-input/) component.
* This is based on Google’s international phone number validation library.
* Ensures numbers are correctly formatted and country codes are recognized.
#### `expression`
* Allows administrators to define a **custom regular expression** to validate the field.
* Flexible option for enforcing format-specific data (e.g., postal codes, IDs).
#### `equality`
* Compares the field’s value to:
* Another field’s value (e.g., "Confirm Password")
* A static constant value
* Ensures consistency and matching where required.
### Configure rules effectively
Start with the minimum needed to identify a customer and issue a pass. Add more rules only when they improve an operational or compliance outcome.
* Use `required` only for information needed during enrolment.
* Use `email` and `phone` for customer contact identifiers.
* Use `equality` for confirmation fields, such as repeated email addresses.
* Test custom regular expressions with expected and invalid values before publishing.
{% hint style="warning" %}
Customize the default email expression only when there is a documented requirement. An overly narrow expression can reject valid customer email addresses.
{% endhint %}
### Validate the form before publishing
Submit the form with representative valid and invalid values. Confirm that required fields block empty submissions, format rules show clear errors, and equality fields reject mismatched values.
Review the result on mobile as well as desktop. Most enrolment journeys begin on a phone after a QR-code scan or campaign link.
### FAQ
Which fields should be required?
Require only fields needed to identify the customer, issue the pass, or meet a documented compliance requirement. Optional fields can be collected later.
When should an expression rule be used?
Use an expression rule when a business identifier requires a specific format that the standard rules do not cover. Test the expression against valid and invalid sample values before publishing.
Can an email address be confirmed?
Yes. Add a second email field and apply the `equality` rule to compare it with the original field.
Why does a valid-looking email address fail validation?
The email rule checks both the address format and whether the domain accepts mail through MX records. Confirm that the domain is spelled correctly and has valid mail records.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.thewalletcrew.io/guides-enrolment/enrolment/enrolment-form/validation-rules.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.