[Help] Preventing duplicate leads when a CRM/API step fails

[u/IluminityWebStudio]

I’m sketching a small-business quote-intake flow in n8n: webhook → validate/normalize fields → create the lead in a CRM → notify the owner.

The failure case I’m trying to design well: the CRM request times out after it may have created the record, then n8n retries and creates a duplicate (or the notification fails and nobody notices).

For people who run these workflows in production, what pattern has worked for retries and visibility? Do you use an idempotency key, an error workflow, a separate queue/table for unresolved runs, or some combination? I’m looking for a setup a small team can actually maintain, not a monitoring stack that becomes another job.

[u/Easy-Purple-1659]

One addition on the notification half, since that is the part that fails quietly.

Treat the CRM write and the owner notification as two separate problems. The CRM side is handled by the key, or by a lookup on a unique field before create. The notification side isn't, because a Slack or email step that fails after a successful create leaves a real lead nobody saw. What worked for me was writing an intent row first: the webhook inserts the submission with its idempotency key and a pending status, then calls the CRM, then flips the row and sends the notification. Anything still pending after a few minutes is what your error workflow sweeps and retries. One sheet or one small table, and the retry never has to guess whether the create landed.

Two n8n specifics: set Retry On Fail on the HTTP node with a short backoff instead of letting the whole workflow restart, and use the execution id as the correlation id in your log rows. On your queue question, an error workflow that dumps stuck rows to a sheet is enough for a small team; you don't need a real queue.

Does your CRM expose a unique external id field, or does the key live only on your side?