C‑01: one customer
The same customer asks about two different jobs. Finding their existing contact does not make the second request a duplicate.
Same customer. New enquiry. Or just the same message twice?
Match the person, keep each genuine request, and recognise a repeated delivery before creating more work. Those are three different decisions. A rule that ignores every message from an existing email address may remove duplicates by throwing away the next sale.
One customer can make two real requests.
Three identities to keep separate. All IDs below are synthetic.
Q‑01 and Q‑02
Keep each genuine request and its next action. Link a reply to the relevant enquiry when a reliable reference exists.
E‑01 arrives twice
E‑01 delivers Q‑01, then repeats. Recognise that repeat and check what already succeeded before creating another record or task. E‑02 delivers Q‑02.
Decide what is duplicated before choosing a tool
If the same person appears twice, check contact matching. If one request appears twice, check enquiry matching. If a task or acknowledgement repeats after a retry, check which actions already succeeded. Start with the CRM’s native matching and add coordination only for the gap you can identify.
Keep the original message when the match is uncertain. A review queue is more useful than a tidy database with an enquiry missing.
One contact can make two real requests
Illustrative example, created for this guide: a small service business receives a form asking for a repair quote. Its connector delivers the same submission twice. A week later, the same customer requests a separate maintenance visit.
The intended result is one contact, two enquiries and the appropriate next action for each enquiry. The repeated first delivery should not create another task. The later request should not disappear because the email address is familiar.
Here, “enquiry” means a distinct piece of requested work. Your CRM might hold it as a deal, ticket or another linked record. Choose the record type your team already uses; this is a proposed design, not a requirement to buy a custom-object feature.
| Identifier | What it identifies | What a match allows you to do |
|---|---|---|
| Contact C-01 | The person or agreed customer identity | Reuse the confirmed contact; still examine the new request. |
| Enquiry Q-01 | One request or job | Attach a reply to the right work, without erasing a different enquiry Q-02. |
| Source event E-01 | One logical event that may be delivered repeatedly | Check and resume its recorded outcome instead of repeating completed actions. |
What does your CRM already prevent?
HubSpot, for example, matches contacts by email. Its documentation says a form submission with an existing contact email adds information to that contact. Secondary email addresses and form settings affect the result, so check the particular form path rather than assuming every external connector behaves the same way.
Company records have a separate exception: HubSpot says companies created through its API are not automatically deduplicated by company domain. Do not apply a rule for native contact forms to every object and integration.
For a custom connection, an upsert means update if a matching record exists, otherwise create. HubSpot’s v3 contacts reference documents batch upserts using email or a custom unique identifier, but partial upserts using email are not supported. Your implementer must check the API version, fields and connector operation actually in use.
These features help match records. They do not, by themselves, decide whether a second message is a new job or whether its follow-up task has already been created.
HubSpot: native deduplication and its exceptionsHubSpot: contacts API, v3 reference
Do not use an email address as the request ID
Use a confirmed CRM record ID when one is available. Treat an email address as a matching clue with a policy behind it: two people can use a shared mailbox, and a customer can write from a different address. Similar names or message wording are reasons to review a possible match, not enough to merge people automatically.
For repeated deliveries, ask the source for an identifier that stays the same when it retries the same logical event. Store the source and account alongside that identifier so unrelated systems cannot accidentally share a key. A new ID generated on every delivery attempt cannot tell you that the underlying event was already handled.
A thread or enquiry reference can link an inbox reply to existing work. It does not prove that every later message in the thread is the same request. A form and an email that look alike but lack a reliable shared reference should remain visible for review.
If the source has no stable identifier, agree how the integration will recognise a retry before enabling automatic creation. Do not quietly substitute “same email within a day”: that can suppress a legitimate second request.
Keep a record of the work, not just the arrival
For a connection spanning a form, inbox and CRM, use this as a design brief for the person building it. A durable receipt is a small processing record that survives a restart and says what happened to one event. Receiving the event and finishing the work need separate states.
HubSpot warns that new or updated records can take a few moments to appear in search. An empty search result immediately after a timeout is therefore not proof that creation failed. Our recommendation is to reconcile a stable reference and the downstream result before issuing another create.
- Check the incoming message. Retain its source reference and the information needed for the enquiry. Route missing or ambiguous identity to an owner instead of dropping it.
- Reserve the stable event key before acting. The store must reject a second simultaneous reservation for the same key. A duplicate should find the existing processing record, not start an independent copy.
- Match the contact and the enquiry separately. Reuse a confirmed contact, attach a reliable reply to its enquiry, and keep a genuinely different request as separate work. Concurrent new events also need protection against creating the same contact twice.
- Record each confirmed action. Keep the CRM enquiry ID and the agreed next-action ID as they become available. Give the action a stable reference tied to its enquiry and purpose; a new incoming message should not automatically mean a new task.
- Handle uncertainty explicitly. If creation may have succeeded but the response was lost, inspect the existing result or route it for review. A receipt marked “started” must not be treated as “completed”. Resume missing steps without repeating confirmed ones.
- Finish with an owner and an outcome. Mark completion only after the intended records and action are confirmed. Keep failed or uncertain work visible to someone who can resolve it.
Where does n8n’s Remove Duplicates node help?
n8n documents separate modes for duplicates within the current input and items seen in earlier executions. Earlier-execution matching can use node or workflow scope. For the “Value Is New” option, the documented history default is 10,000 items; history can also be cleared.
That can help filter repeated items, but choose the fields deliberately. Comparing only email would confuse a returning customer with a repeated request. Check the installed node version and the scope and history settings.
A remembered ID is not evidence that the next CRM action succeeded. Use duplicate filtering as one part of the workflow, alongside recorded downstream outcomes and recovery. Do not promise exactly one task merely because a Remove Duplicates node is present.
Eight cases to try before switching it on
These are proposed acceptance tests with invented records, not results from a HubSpot or n8n account. Use a test destination with no real recipients. For each case, inspect the CRM records and processing receipt as well as the workflow log.
The downloadable sheet includes blank result and notes columns. Record what your setup actually does, the relevant record IDs and any correction needed. Also try case 2 with both deliveries arriving together; sequential retries alone do not check concurrent processing.
| Test input | Expected behaviour | Evidence to inspect |
|---|---|---|
| 1. First enquiry Q-01 from contact C-01 | Keep the enquiry, correct contact and owner, with the agreed next action once. | Source message, contact link, owner and next-action ID. |
| 2. Deliver event E-01 twice | Recognise the repeat; reconcile completed work and resume only missing steps. | One enquiry and action; no repeated acknowledgement. |
| 3. C-01 sends a different enquiry Q-02 | Keep the same contact and both genuine enquiries. | Q-01 and Q-02 remain visible with their own next actions. |
| 4. Reply with a reliable Q-01 reference | Attach the reply and review the existing next action. | Reply visible on Q-01; no unnecessary new enquiry. |
| 5. Similar form and inbox messages, no shared request reference | Retain both messages and flag a possible match for review. | No automatic merge based only on contact or wording. |
| 6. An enquiry has no email address | Keep the request and route uncertain contact matching to an owner. | No dropped enquiry or invented identity. |
| 7. Two people use a shared role address | Apply the agreed mailbox policy and keep their requests distinguishable. | Ambiguous contact changes are reviewed. |
| 8. CRM creation succeeds but the confirmation is lost | Reconcile the first result before creating again; resume incomplete work. | One enquiry; recovery recorded; completed actions preserved. |
Start with one form and one inbox
Write the matching rules down before changing the integration. Choose one intake path, run the synthetic cases, and give unresolved items a named operating role with a backup. Agree who can pause automatic creation if the results stop matching the rules.
Once intake is dependable, stage-based follow-up can handle the next expected action, while a CRM exception view catches work that slipped through. Keep these responsibilities distinct so a cleanup rule does not accidentally become another task generator.
Before adding a tool, include the time someone will spend reviewing exceptions and maintaining the connection. Explore your existing form, inbox and CRM in the tool connection map, then scope the particular gap you need to close.
Plan follow-up tasks around CRM stagesCreate a useful CRM exception queueEstimate build and ongoing automation costsExplore your tools in the connection map
Sources
Which enquiry keeps appearing twice?
Tell forvertz which form, inbox and CRM you use, and what repeats. We can help scope one intake path around the available connections, matching rules and exceptions.
Discuss one enquiry workflowUpdated