A reliable integration starts with two questions: where is an enquiry saved before delivery to CRM, and how does the system recognise a repeated delivery? A neat “form → n8n → CRM → notification” chain is not enough: CRM may respond late, a notification may fail and a visitor may click twice. Below is a design you can test with training data before launch, then give a developer as a technical brief.
What counts as an accepted enquiry?
Separate three events: the site accepted an enquiry, CRM created a record and a salesperson received a notification. These are not the same event. If the visitor sees “Enquiry sent”, a record must already exist that can be found and recovered after a failure. An email or messenger notification is no substitute for that storage.
A practical design: the website server validates mandatory fields, assigns an enquiry identifier and saves both the data and a delivery job. It responds to the visitor only after successful storage. A separate process delivers the job to n8n; n8n follows the CRM workflow and returns the result. This is an architectural recommendation: a Webhook node alone does not mean your website has a reliable queue.
For a small project, storage may be a native CMS entity or a developer-maintained table. The technology’s name matters less than verifiable behaviour: the record survives a restart, its state is visible and repeated processing can be controlled. If storage cannot be confirmed, the interface must not show successful submission.
Step 1. Agree minimal data and an identifier
A training form needs only a name, contact method and task description. Also send the form code, page URL, acceptance time and agreed source tags. Store consent fields and the corresponding text version according to the site’s established process. Do not send all browser data through the workflow “just in case”.
| Field | Purpose | Training value |
|---|---|---|
| request_id | Enquiry identifier | demo-2026-0042 |
| form_code | Source within the site | project_request |
| delivery_state | Delivery state | pending |
All example values are fictitious. A real identifier is generated by the server or a trusted form mechanism; it should not merely be an attempt number. Repeated delivery of the same enquiry retains its identifier. A genuinely new enquiry from the same person receives a new identifier.
Do not use a telephone number as the sole duplicate criterion. One person may enquire about two projects; several employees may share a number. Separate redelivery of one event from merging customer contacts. The first requires technical idempotency; the second follows CRM rules and sometimes a salesperson’s decision.
Step 2. Separate test and production endpoints
The n8n Webhook node has separate test and production URLs. Current documentation associates the production endpoint with a published workflow and the test endpoint with listening for events during development. Switch labels may differ in your installed version. Before connecting a form, check the Webhook documentation and verify the URL, request method and response mode.
Keep integration secrets on the server, not in page JavaScript. Browser requests are visible to visitors; a secret embedded in a form is no longer secret. Typically, the public form calls its own server, which then calls the protected integration endpoint. Public intake also needs rate limits, payload-size validation and spam controls.
Define what a successful HTTP response means. “The webhook received the request” and “CRM created a deal” are different guarantees. A quick response is acceptable when data is durably saved and subsequent delivery is tracked. If the sender waits for the whole chain, it may time out even though CRM already created the record. Test that case explicitly.
Step 3. Make repeated processing safe
Create a mapping log containing the enquiry ID, status, CRM ID, last-attempt time and a short error code. Before creating a record, the integration must check whether the enquiry was processed. However, “search, then create” alone is insufficient: two parallel requests may both find nothing and proceed.
The developer must claim an event for processing atomically, for example through a unique identifier constraint and a storage transaction, or an appropriate native mechanism. Check whether the particular CRM API method supports an external identifier or idempotency key. Do not assume every deal-creation method provides this protection.
After successful creation, save the CRM identifier before sending optional notifications. If a notification fails, retry the notification rather than creating the deal again. Useful separate states include awaiting delivery, processing, created in CRM, needs review and complete. Names may vary; transitions must remain understandable to the operator.
Training example: CRM created a deal, but the response was lost
The site saved enquiry demo-2026-0042. n8n sent it to CRM, which created training deal 1052. The connection broke before the response arrived. Execution appears to have failed, but repeating the create request could produce a second deal. Automatically “retrying every error five times” is dangerous here.
The correct branch depends on the API. If the method guarantees idempotency, retry with the same key under the CRM’s rules. Otherwise, first search using the saved external identifier. Link an unambiguous matching record. If the result remains uncertain, move the enquiry to manual review while retaining its original data. Do not blindly create another deal.
Use a test CRM or explicitly agreed training records. Do not simulate failures on real enquiries. The test should produce one enquiry and one linked record despite retries, or a clear operator task when the outcome is uncertain. Promising “exactly once” delivery without verifying every participating system is inappropriate.
Step 4. Classify errors by cause
| Failure | Response | Check |
|---|---|---|
| Temporary unavailability | Bounded retries | Interval and overall deadline |
| Incorrect permissions or fields | Stop and investigate | API response and data schema |
| Unknown operation outcome | Reconcile with CRM | External ID and log |
Retries need a limit, a pause and a terminal state. When rate-limited, follow the API’s rules instead of increasing parallel attempts. An authentication error will not fix itself on the tenth identical request. A missing mandatory field needs corrected data or routing, not an endless queue.
n8n allows a separate error workflow starting with Error Trigger. This helps report failures but does not replace enquiry storage, duplicate protection or retry planning. Check the official error-handling guide. Notifications should contain an identifier and a review link, rather than the full enquiry and personal data in a shared chat.
Step 5. Run scenario-based acceptance tests
- Submit one valid training enquiry. Find it on the site, in the log and in CRM; match the identifiers.
- Redeliver the same event sequentially, then in parallel. Check the CRM record count.
- Send a new enquiry using the same training contact. Confirm that crude duplicate filtering does not discard it.
- Test a missing mandatory field. The error should be understandable and the original record available for correction.
- In the test environment, reproduce CRM unavailability and an uncertain response after record creation.
- Separately disable a test notification. The existing CRM record must not be recreated when notifications recover.
- Restart the test worker between acceptance and processing. Confirm that the accepted enquiry survives.
- Compare accepted, processed and pending counts. Every discrepancy must have a known state.
Save training-event IDs, times and expected versus actual results, not just a screenshot of green nodes. An n8n execution is an individual workflow run; execution history is described in the Executions documentation. History availability and retention depend on settings and the offering: check them before launch rather than assuming an unlimited log.
Launch, monitoring and rollback
Move one agreed form to the new chain first. Record the switch time, workflow version and queue state. Do not send every live enquiry through both old and new routes without duplicate protection. Monitor at least the oldest unprocessed record’s age, error count and events without a confirmed CRM record.
For rollback, restore the previous intake route, stop unsafe retries from the new version and retain its log. Reconcile events from the switching period: which are already in CRM, which were only accepted and which need review. Resending the entire list without reconciliation can create duplicates even after the underlying fault is fixed.
Assign someone to manage the queue and define an acceptable response time. Automation without an owner for failures turns visible manual work into invisible losses. At low volume, daily reconciliation may be more sensible than elaborate monitoring; urgent enquiries need faster intervention. Choose the interval by the process, not by how impressive a dashboard looks.
When n8n is not yet necessary
If a native CRM form already saves enquiries reliably, transfers the required fields and provides error history, another intermediary may only add failure points. Start by checking the current route. n8n becomes useful when you need multiple systems, data transformation, branching and controlled exception handling. A more expensive plan does not itself solve duplicate records.
Key terms: idempotency means repeating one event does not create a new result; a queue stores jobs for controlled processing; a timeout means the wait expired, not necessarily that no result exists; reconciliation compares accepted enquiries with CRM records. A completed test matrix supports independent acceptance or a brief for website-to-CRM integration.
Apply this to your own project
Describe a reliable enquiry route, separate acceptance from notifications and test duplicates, temporary failures and unknown CRM creation outcomes.
Website → n8n → CRM acceptance tests: open the worksheet · Download the CSV to complete. Free access, no registration. Use it independently or pass it to your contractor.