Build Notes: Sending a Lead Form to a CRM Without Losing a Row

A reliable lead form to CRM connection saves an accepted submission before forwarding it, records what happened at the CRM, and keeps a safe way to retry. A daily check should compare accepted submissions with their destination records and agreed exclusions. A success message on the website alone proves very little.

One common failure is quiet. The form posts, the CRM is slow, the request times out, and the page looks finished. Nobody notices the gap until a customer asks why nobody called back. The fix starts with a receipt, not another animation on the submit button.

What counts as an accepted submission?

Define acceptance at the form’s own server. Required fields must pass server-side validation, and the submission must be saved durably before the visitor is told it was received. The browser’s validation is useful feedback, but a caller can send a request without using the browser at all.

Separate receipt from delivery. “We received your enquiry” can be true while the CRM connection is temporarily waiting. “Your appointment is confirmed” would require a different completed action. The message should match the state the system can prove.

Record spam and invalid submissions separately from accepted enquiries. If those records are mixed together, a daily count can look wrong even when delivery worked. Decide what qualifies as a lead before deciding how many the CRM should contain.

Save a receipt before forwarding the lead

Give each accepted submission a stable ID and save its received time, source, delivery state, and retry history. Store the lead’s details where the worker can recover them. A log line that says a request arrived is not enough if the original payload disappears when the process restarts.

Here is a hypothetical delivery receipt, with sample data:

{
  "id": "sub_2026_10_05_example",
  "received": "2026-10-05T09:14:03Z",
  "source": "/contact",
  "status": "pending",
  "attempts": 0,
  "crmRecordId": null
}

Keep the receipt in a store the business controls. Restrict access to personal details, avoid putting full messages into general diagnostic logs, and set a retention rule that fits the actual enquiry process. The receipt exists to recover delivery, not to create an unowned archive of customer data.

Confirm delivery instead of assuming it

Mark a receipt as delivered only after checking the CRM’s response and saving a destination reference. A completed network request can still contain an error. MDN’s guidance on Fetch explains why applications must check response status rather than relying only on a rejected promise.

Map fields explicitly. Decide which form value becomes the contact name, enquiry message, source, and assigned owner. A field rename in the form should fail visibly rather than silently place the message into the wrong CRM property.

Separate the contact from the enquiry when the CRM supports that structure. An existing customer can submit another request. Updating their contact details should not erase the earlier conversation or make the new request disappear from the queue.

How do retries avoid duplicate records?

Every retry should reuse the original submission ID and a delivery operation designed to tolerate repetition. A timeout can mean the CRM never received the request, or that it received it but the confirmation did not get back. Sending a new create request without checking can make duplicates.

The destination’s rules matter. HubSpot’s contacts documentation supports upserting contacts using email or a custom unique identifier, with limitations that differ between them. Other CRMs need their own supported approach.

Choose the key for the record being written. An email can identify a contact but does not identify every enquiry that contact sends. Preserve a submission-level reference for the enquiry and store the returned contact ID separately.

Avoid promising exactly-once delivery across services. Plan for repeated attempts, then make the result safe to repeat.

Decide what gets retried and who gets alerted

Temporary service failures can be retried after a growing wait, within a defined limit. Invalid fields, missing permissions, or an expired credential need intervention. Repeating the same bad request indefinitely produces noise and leaves the original enquiry waiting.

Use a simple recovery table:

Delivery state	Next action
Pending	Worker attempts delivery
Temporary failure	Retry after the agreed wait
Invalid data	Send to review with the field error
Repeated failure	Alert the owner with the receipt ID
Delivered	Keep the CRM reference and confirmation

An alert should tell the owner what failed, where the saved enquiry lives, and how to replay it safely. Include a fallback if the alert channel itself is unavailable. Nobody should have to reconstruct a customer’s message from a screenshot.

A hypothetical test of the failure path

Suppose a form accepts an enquiry and the worker sends it to a test CRM. The CRM creates the record, but the connection closes before confirmation. The receipt remains uncertain. On retry, the worker uses the same submission reference and finds or updates the existing enquiry instead of creating another one.

Test the opposite failure too: the destination never receives the request. The saved receipt remains available, the retry eventually delivers it, and the CRM reference is written back. Then try an invalid required field, an expired credential, and a process restart while an item is pending.

Each test needs an expected end state. A screenshot of the CRM containing a lead cannot prove the retry path worked. Compare the receipt, attempts, and final reference. The handoff test is useful here because another teammate should be able to replay a failed item without asking the builder.

Reconcile the received and delivered records

Compare unique accepted submission IDs with confirmed destination references, pending items, and documented exclusions. A simple subtraction of form count minus contact count can mislead: repeat customers may update one contact, while test submissions or rejected spam may be intentionally excluded.

Make the remaining differences actionable. List the receipt ID, age, current state, and owner. Check for enquiries stuck pending, delivery marked complete without a reference, and destination records missing their submission ID. Investigate the reason, then repair the individual record.

Also check whether someone actually owns the follow-up after delivery. Reliable transport does not guarantee a reply. The website and CRM guide follows the rest of that path.

Frequently asked questions

Is an email notification enough to protect a lead?

An email can be a useful alert, but it is not a durable delivery record or a safe retry mechanism. Keep a receipt that can recover the submission independently of the notification.

Should every failed request be retried?

No. Retry temporary failures within a defined limit. Send invalid data, missing permissions, and credential problems to an owner who can fix the cause before replaying the saved submission.

Can the same person submit more than once?

Yes. Treat the contact and each enquiry as different records or references. Matching a contact by email should not discard a later enquiry or overwrite the history of an earlier one.

What should be checked before launch?

Check durable receipt storage, field mapping, delivery confirmation, safe retries, failure alerts, and reconciliation. Then test the path with the CRM unavailable and with an uncertain confirmation.

Before changing the form design, follow an accepted enquiry all the way to a named owner. If that path cannot be explained and recovered, the connection needs attention first.