Form validation: choosing required fields and testing error messages

A registration form needs an email address if the organizer sends entry instructions by email. A general feedback form may have no use for a phone number. Set Required after deciding what the organizer will use, because a missing required answer blocks the respondent from submitting.

ThunderForms checks the active page when someone presses Next. Submit checks all fields, and the server validates the answers again against the saved form before storing a response. A required question on page one can therefore prevent someone from ever reaching page two.

Check what the rule accepts

Required checks for a missing value. For example, an empty text answer or an empty list of selected options fails that check, while false is an answer to a boolean question. A required answer can still fail its field's other rules, such as an email address with an invalid format.

A slider's configured starting value is already in the public form's answer data, so making it required does not prove that a person moved it. If an explicit response matters, use a field that starts unanswered and verify that submitting it blank produces the error you expect.

For a whole-number quantity from 1 to 20, use a number field with decimals disabled and those bounds configured. Single-select and radio questions check that the submitted value belongs to their saved options. Date controls can apply configured date limits. For a date limit, try the day before and the day after it as well as the boundary itself.

Explain special formats beside the field

An email field checks email syntax. It does not confirm that the mailbox belongs to the respondent or can receive your message. Phone mode needs additional rules if you want to enforce a particular format, so check the saved settings before relying on it to reject invalid numbers.

Text Input and Text Area have a Regex setting for enforcing formats such as AB-1234. A rule such as ^[A-Z]{2}-\d{4}$ matches that whole format, including the anchors that prevent it from accepting a matching sequence inside a longer answer.

Use a message such as "Enter two capital letters, a hyphen, and four digits, for example AB-1234." Keep the description and mismatch message consistent if the format changes. Regex is optional. Enable it only when the receiving process needs the restriction, and test valid codes as well as malformed ones.

Try an incomplete submission on a phone

Open the public form at a narrow screen width and leave a required field blank. Press Next if the form has multiple pages. The current page should stay open with an error at the field, and the answers you entered elsewhere should remain available when you correct it.

Then enter an invalid email and a number outside its configured range. Check each message. Correct those answers, go back to an earlier page, and return before submitting to test navigation and recovery using the same controls respondents will use. Leave an optional text question blank on the successful attempt to confirm that it can be skipped.

Changing one rule does not guarantee a higher completion rate. The result depends on the audience and the rest of the form. If you measure a change, record the form version and collection period along with the response counts so the comparison has enough context to use.

Make a test matrix for every rule

Write one valid and one invalid example for each constraint before publishing. For an email field, submit a normal address and then a value without an at sign. For a quantity from 1 to 20, try 1, 20, 0, 21, and a decimal if decimals are disabled. For a required choice, try both a selected option and no selection. Record what the respondent sees and whether the answer is saved.

A format rule can reject answers that are valid for some respondents. Before enforcing uppercase letters, fixed punctuation, or a single date format, check a real example from the people who will use the form. Include spaces, international phone formats, or leading zeroes when they are meaningful. If a field needs a correction message, name the exact change the person should make rather than repeating "Invalid input."

Keep the test copy separate from live submissions. When the form changes, re-run the cases affected by the edit, plus one end-to-end submission to confirm that navigation and saving still work together.

Open your questions in the builder and check the saved Required, format, and range settings before running that test on the public link.