Build forms that do not lose leads.

The submission flow

Follow the sequence below from start to finish. The order matters: later steps assume the earlier ones are done.

1. Collect only the fields needed for the next decision.
2. Validate required values and length on the client for fast feedback.
3. Submit a normalized payload to the database.
4. Enforce the same safety limits with database policy or server-side validation.
5. Show success only after the write returns successfully, then trigger notification handling.

Useful form states

The list below breaks this down into the parts that matter most. Read through each one and note anything that applies to your own setup.

• Idle: the form is ready.
• Submitting: disable repeat submission and preserve entered values.
• Success: confirm what happened and what happens next.
• Error: explain the recovery action without exposing backend details.
• Validation: point to the field that needs attention.

Keep user-facing copy concise. A form should not promise a response time or outcome that the business cannot consistently deliver.

Email notifications

Save first, notify second. If sending fails, retain the submission and make the delivery status observable rather than asking the visitor to submit again.

Pre-launch checklist

Before making changes, work through the points below. Each one covers a different part of the picture, so treat them as a set rather than picking favourites.

• Submit with every required field empty and confirm each error message is specific.
• Submit with an oversized payload or long text field and confirm the database policy rejects it rather than the client alone.
• Disconnect the network mid-submission and confirm the form recovers to a retryable state.
• Confirm the saved row includes a timestamp and, where relevant, a source or page identifier for later reporting.
• Confirm a second, identical submission within a few seconds does not create a duplicate row.

Warning signs of a fragile form

A few moving parts are involved here. The points below cover each of them, so you can see the full scope before deciding where to start.

• Success message shown before the database write has resolved.
• No record in the table for a submission the visitor insists they made.
• Validation only exists in the client component and is absent from database policy.
• The submit button can be pressed repeatedly during the pending state.
• Personal data fields exist in the schema with no stated reason for collecting them.

Frequently asked questions