Event registration field validation rules
The registration export is full of emails without domains, phone numbers in six formats and names typed in capitals, and the badge list is due on Friday.
The short answer
Validate to protect the next use of the data, not to police the delegate. For each field, write what the data is used for, what a usable value looks like, and what happens when the value does not match.
Prefer a warning with an easy way to continue over a hard block, except for the few fields the event cannot run without.
Start from use, not from format
A field is worth validating strictly only if a later step breaks without it: an email for the confirmation, a name for the badge and certificate, a membership number for the rate.
Write the downstream use beside each field in your data dictionary. If you cannot name the use, ask whether the field should be collected at all with the field minimiser tool.
Three levels of response
| Level | Behaviour | Suits |
|---|---|---|
| Block | The form will not submit until fixed | Email used for confirmation, consent tick-boxes the event legally or contractually needs confirmed, mandatory category |
| Warn | A message appears but the delegate may continue | Phone number format, unusual characters in a name, company name looks like a personal email domain |
| Clean afterwards | Accept the value, tidy it in the export | Capital letters, extra spaces, title formats, dietary free text |
Rules that cause trouble when too strict
- Names: do not reject apostrophes, hyphens, single-word names, spaces or non-English characters. Allow long names; check the badge layout separately.
- Phone numbers: accept country codes and common separators, and store a cleaned version alongside what was typed.
- Dates and times: show the format expected and the time zone if delegates travel.
- Identity numbers: ask whether any are needed at all. If one is, ask the competent party how it should be collected and stored.
Write the rule as a sentence and a test
- Name the field and the use.
- Write the accepted pattern in plain words.
- State the level: block, warn or clean afterwards.
- Write the message the delegate sees.
- Write two valid and two invalid sample values and test them before launch, using the registration testing checklist.
Worked example · Fictional example
Validation sheet for a one-day regional conference
Fictional organisation and figures, for illustration only.
A fictional engineers' institute reviews its form after a pilot. Phone numbers were blocked for missing a plus sign, so several delegates entered placeholder numbers. The team changes the rule to warn, and stores a cleaned copy.
It keeps a hard block only on the email address and the category choice, and adds a name preview that shows how the badge will look. Test values include a name with an apostrophe, a name of one word and a very long double-barrelled name.
Use this yourself
Field validation sheet
Copy one row per field. Complete every column before the form is built.
| Field | Used for | Accepted values in plain words | Block / warn / clean | Message shown |
|---|---|---|---|---|
| Full name | Badge, certificate | Any letters, spaces, hyphens, apostrophes | Warn | Please check spelling, this is printed on your badge |
| Confirmation, joining details | One address with a domain | Block | Please enter an address we can send your confirmation to | |
| Phone | On-day contact | Digits with optional country code | Warn | Check this number, we may need it on the day |
| Category | Rate, access | One option from the list | Block | Please choose one |
Handle it in-house, or bring in help?
Your team can usually handle this when
- Your form has fewer than ten fields and one person tests it.
- The platform provides standard validation and you only adjust messages.
- Exports are cleaned by the same person who reads them.
Outside planning help earns its fee when
- Data flows to badge printing, certificates, finance and a customer system with different rules.
- Delegates from several countries are failing the form.
- Nobody has time to test with realistic fictional delegates before launch.
Want the field rules written and tested?
A conference project lead can turn your data dictionary into a validation sheet, run the test cases with sample delegates and coordinate the fixes with your registration platform contact. What data you collect, and why, stays your organisation's decision.
Questions organisers ask
Should we validate email addresses by sending a code?
Only if a wrong address would cause real harm, such as lost joining details. For most events, a clear confirmation page and a reminder to check the address are enough.
How strict should name validation be?
Loose. Accept the characters real names contain and use a preview to catch layout problems, rather than rejecting names that look unusual.
Who should test the form?
Someone who did not build it, using a list of fictional delegates that includes awkward but valid cases.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.