Validating form data: field rules and patterns that stop bad answers at the door

A phone number with a missing digit. An age of 1200. A national ID typed with letters in it. Each of these takes a second to refuse at the moment it is typed, and an hour to find later in a spreadsheet, once the data has been summed, charted and sent to someone. Validation is the habit of refusing the bad answer at the door.

This article explains the two tools a form gives you for that, rules for each field and patterns, how far each one reaches, and what to do with the answers they cannot stop.

Rules for each kind of field

The simplest checks depend on what kind of answer a field holds:

Use the Number type for anything you will add up or average. Numbers typed into a text field cannot be summed or sorted properly, so the cheapest validation of all is choosing the right field type.

Patterns: describing the exact shape of an answer

Some answers have a fixed shape that no range can express: a mobile number, a national ID, a reference code. For these you set a pattern, also called a regular expression or regex, which describes exactly what the answer must look like.

For example, ^07[0-9]{8}$ means: start, then 07, then exactly eight more digits, then end. That is a ten-digit mobile number starting with 07, and nothing else.

A few things worth knowing:

• The pattern must match the whole answer. [0-9]+ accepts digits only and refuses 0591234567abc. For a fixed length, say so: ^05[0-9]{8}$. A lone [0-9] means exactly one digit.
• Patterns work on Arabic text. The ready-made Arabic letters only format accepts Arabic letters and spaces, so a name of two or more words written in Arabic passes, while digits and Latin letters are refused. (Writing ^\p{Arabic}+$ yourself is looser than it sounds: it accepts anything in the Arabic script, including Arabic-Indic digits, diacritics and Persian letters, and it refuses spaces.)
• You can write the message people see when their answer does not fit, in plain words, so they know what to correct.
• A broken pattern is refused when you save, for example one with an unclosed bracket, so a mistake in a pattern can never lock everyone out of a field.

You do not have to write one

Most people who build forms cannot write a regular expression, and they should not need to. Pulseform's Pattern helper sits beside the pattern box. You pick a ready-made format such as Mobile number, set what it starts with and how many digits it has, and press Use this. The pattern and its error message are filled in for you, and Try a value shows which formats accept what you type.

Even so, test your pattern on a few real examples before you publish, including awkward ones. A pattern that is too strict blocks valid answers, and one that is too loose lets bad data through.

Where a pattern is checked, and where it is not

This is the part most guides skip. A rule is only as good as the places it is enforced.

Why not in the field? A phone with no connection cannot judge a pattern reliably, and if the app accepted an answer that the server later refused, the collector's answer would be lost after the interview was over. So field collectors are not held to your patterns. Their answers are always kept. Other rules, such as required questions and number ranges, are still checked on the device.

When you issue a collector code for a form or survey that has patterns, you are asked to confirm that they will not be checked in the field. The confirmation is asked every time, and while a form has patterns and a working code, its header carries a reminder.

What to do with answers that do not fit

An answer from a field collector that does not match its pattern is kept and counted like any other, and marked so you can find it:

• In the record's details, the field shows Does not match the expected format.
• In the list of records, set the Format check filter to Only records that do not match to see just those.
• The CSV export has a last column, Format Check, naming the fields concerned.

If you later add, change or remove a pattern, the marks are updated for every field-collected record of that form.

Review the marked records for typing mistakes, such as a number with a digit missing, and follow up with the collector. They are never rejected or hidden on their own.

When to use a pattern, and when not to

• Use one for answers with a fixed shape: phone numbers, national IDs, reference codes, postcodes.
• Do not use one for free text such as comments or names, where a strict shape would only reject real people.
• Prefer a rule to a pattern when a rule can do the job: a number range is clearer than a pattern for digits.
• Keep the error message kind. "Enter a ten-digit number starting with 07" is better than "Invalid".

What to ask of any form tool

Whichever tool you use, ask:

1. Does it offer rules for each kind of field, not only "required"?
2. Can I describe a fixed shape with a pattern, and does the pattern have to match the whole answer?
3. Is there help for people who cannot write a regular expression?
4. Does it work on Arabic text?
5. Is the rule enforced on every channel: the public link, an imported file, and a field team?
6. What happens to an answer it cannot check? The safe design keeps it and marks it for review.

In Pulseform

Field rules and patterns are set in More Settings on each field of a form. The same custom pattern exists for text questions in surveys. See building a form and its field rules, answers that do not fit the pattern, custom patterns in the field and issuing collector codes in the guide.