Duplicate lead records often appear when a workflow receives the same submission more than once or retries after a partial failure. Simply searching for an email address is not always enough: one customer may make several legitimate enquiries.
Before building the Airtable and Make workflow, define what counts as the same event and what counts as a new request.
Separate the person from the enquiry
Use a stable submission identifier from the source where available. Keep that identifier with the processing record so a retry can be recognised.
A customer record and an enquiry record serve different purposes. The same email address may identify a person while a new project still needs a separate enquiry.
For a hypothetical service business, a customer asking about a second property should not have that request silently discarded as a duplicate.
Normalise inputs carefully
Trim accidental spaces and apply agreed formatting to fields used for matching. Preserve the original information when it is needed for review.
Do not make aggressive assumptions about names, shared email addresses or phone numbers. When a match is uncertain, route it for review rather than overwriting a record.
Document the matching rule beside the workflow so future changes do not introduce conflicting behaviour.
Consider simultaneous events
A search followed by a create action can race if two executions run together. Discuss sequencing, unique constraints or an appropriate event store with the person implementing the integration.
The goal is that repeating the same event does not repeat its effect. Confirm how that behaviour is achieved in the actual system rather than assuming a visual workflow guarantees it.
Test retries after the record has been created but before the final acknowledgement. This is a common place for apparently failed work to be repeated.
Plan recovery and ownership
Record processing states and errors without storing unnecessary sensitive data. Decide who receives alerts and how a failed item can be resumed safely.
Review Make’s error-handling documentation for the current platform mechanisms. The business rules still need to explain whether retrying is safe for each step.
Test these cases and keep the expected record count and outcome for each:
| Test | How to run it | Expected result | If it fails |
|---|---|---|---|
| Retry of the same submission | Send the same form submission twice | One enquiry record | Check the stored submission identifier and the match rule |
| Two simultaneous submissions | Submit the same data twice at once | One enquiry record | Add sequencing or a unique constraint |
| New enquiry from the same person | Same email, different property or project | Same customer record, a new enquiry record | Loosen the match so it keys on the enquiry, not only the email |
| Failure after creating the record | Stop the scenario just before the final step | Retry resumes without a second record | Record processing state and check it before creating |
| Uncertain match | Similar name, shared email | Goes to a person for review, nothing overwritten | Add a review route |
DonutLabs’ Airtable and Make integration service can help design this behaviour. Bring the source fields and examples of legitimate repeat enquiries so the workflow protects both data quality and customer requests.
For the wider planning context, read Turn website enquiries into quote drafts with human approval.
