Prevent Duplicate Pipedrive Records from Form Submissions

Give the person and the enquiry different keys.

A person can ask about two projects. If you use the person’s identity as the enquiry key, the second legitimate request may disappear. If you create a new person for every delivered event, repeated webhooks can create duplicate contacts.

Define a contact-matching rule appropriate to your data. Separately, preserve a stable submission identifier from the form or its delivery system. Generate that identifier once at submission time, not afresh on every retry. An ambiguous match needs a visible review path.

Prevent duplicate Pipedrive contacts with Make: define the match first.

Email is a useful candidate lookup, not a universal identity guarantee. Decide how to handle missing email, changed addresses, shared agency inboxes and multiple matching people. Normalise values under a documented rule; do not silently collapse distinct people or overwrite established details. Route ambiguous matches to review.

Use an exact search under that policy, verify the candidate fields, then reuse the confirmed person ID. Treat a new submission ID as a possible new enquiry even when the person already exists. Searching for that person does not prove that the enquiry has already been processed.

Pipedrive’s Merge Duplicates documentation describes possible duplicate contacts. Merging contacts is different from ensuring that one webhook submission produces only one intended set of writes.

Pipedrive’s duplicate rules for imports describe that import process. They do not establish that your API or Make scenario prevents duplicate deliveries. Test the route you actually use.

Give the enquiry key a searchable home in the original destination write. Use a dedicated text deal field, then verify that exact field on any returned search candidate. Keep the selected service and contact key with the event record so a changed payload can be detected. The step-by-step test route names the required decisions and destination checks.

Identify what repeated.

A repeated delivery and a new request need different outcomes. Start with the event key, the relevant payload, and evidence of any completed writes.

Keep the result with the event.

Before building modules, define a small record for each enquiry: submission key, a stable fingerprint of its relevant content, processing state, resulting person/deal/activity IDs, attempt history and any unresolved issue. Use the state to decide what can happen next.

The normal path is received → processing → completed. If a key, match or write is unresolved, processing moves to review. Reconcile it before a deliberate retry returns to processing.

This is an editorial state model, not a promise about a particular Make module. The chosen storage and processing mechanism must support the ownership rule you need. Verify its behaviour with two concurrent deliveries.

Make the processed-event record durable.

Use persistent storage shared by every writer of this route. Scope the key with the form or source plus its submission ID so two sources cannot accidentally reuse the same key. Keep a fingerprint of the relevant payload, per-step status and confirmed destination IDs. A repeated key with different content belongs in review rather than being skipped as an identical replay.

1. Validate and claim. Establish the event key and acquire ownership using a mechanism whose uniqueness or locking behaviour you have verified.
2. Write and record progress. Save the person, enquiry and activity IDs as each step is confirmed. Put the enquiry reference in a destination field that you can retrieve and verify.
3. Complete deliberately. Mark the event complete only after the intended records and next action are confirmed. An identical replay then returns the existing outcome.
4. Retain and reconcile. Choose a retention period covering the source’s retry and replay window. Define how stale processing claims are reviewed and released; a timeout must not automatically authorise another create.

A separate “does this key exist?” check followed by an insert is not an atomic claim. A Make data store or external database is a storage choice; its name alone does not prove the protection you need. Test the configured mechanism. If you cannot establish exclusive ownership, serialise the single writer or keep uncertain events in a controlled review queue.

CRM writes and the event log can fail independently. If the CRM write succeeds but its ID never reaches the log, the retry must reconcile the destination first. The webhook queue and short-lived execution history are not a substitute for your durable outcome record.

A search can be correct and still race.

Two runs can both search, find no matching record, and then both create one. Make documents parallel processing for instant webhooks. Its Process data in order setting makes a scenario wait for the previous execution before starting the next.

Coordinate both identities when needed. Claiming E-001 and E-002 independently can stop a replay of either event, but two valid enquiries from the same new person may still race during contact creation. Protect the contact-matching/create step across writers too, or reconcile it under an explicit review policy.

That setting can help within the configured scenario. It does not by itself prove uniqueness across other scenarios, manual actions or retries after an uncertain write. If several writers exist, use a documented shared coordination mechanism or a reviewed manual exception path. Do not claim atomic protection until you have verified it.

The Make webhook documentation is the source for its processing modes. The acceptance cases below are our proposed checks.

A timeout does not tell you whether the write happened.

Suppose Pipedrive creates the deal, but the connection fails before your scenario receives or stores the ID. Repeating the create step could add another deal. First reconcile the destination using the stable reference and the evidence available for that attempt.

If you cannot establish the result, preserve a visible review state instead of calling the handoff complete. Record who will resolve it and how. A manually resolved case is acceptable when it is explicit; a silently lost enquiry is not.

Make’s incomplete executions and Retry error handler support recovery. Incomplete executions are disabled by default; enable Store incomplete executions in Scenario settings (incomplete-execution documentation checked 4 October and rechecked 5 October 2026). Their configuration does not establish your business-level duplicate rule. Check the stored failure, the resumed step and the final CRM records together.

Check recovery scheduling separately. Make documents automatic retry for several temporary errors; it can start again at the failing module. A failed acknowledgement after a successful create must not lead to another blind create. For the controlled test, configure the Retry handler with automatic completion off and verify the observed fault behaviour. Reconcile the destination before any manual resume. Automatic retry documentation.

Nine cases to run before launch.

Use a test pipeline and synthetic records. Start each case from its specified baseline. This kit assumes one deal and one next activity per new enquiry; if your business uses leads instead, adapt the expected result explicitly before testing.

Open a case for its baseline and procedure.

Use the test kit.

The input pack defines the cases and expected outcomes. The result template starts with every case marked not_run. Replace symbolic IDs with your own test references and keep personal data out of anything you publish.

These are test specifications. They do not connect to an account, create CRM records or certify an integration.

To prepare or send the synthetic events, use the Node test sender with the test-runner instructions. Its default creates a dry-run plan. D02 sends ten deliveries of one event; D03 sends two overlapping requests. Live delivery requires an explicitly confirmed test endpoint and baseline. An HTTP acknowledgement does not pass a CRM acceptance case.

Recover deliberately.

• Inspect the event key, relevant payload and confirmed destination IDs.
• Check whether the uncertain write already reached the destination.
• Name the owner of each unresolved case and record the recovery action.
• Resume only when the next write has a defined expected outcome.
• Inspect final records and follow-up visibility before accepting the result.

Count recovery work in your plan.

Once the route passes, measure the credits for each path and its extra attempts. Use the Make credit estimator to turn those observations into a monthly planning estimate.

If the process is still being designed, return to the form-to-Pipedrive guide. A stable manual handoff may be a better current choice than an unverified automation.

Version notes: check the fields you actually map.

Make’s Pipedrive documentation records API v1/v2 changes. Its stated v1-module deadline was 31 July 2026; for an older scenario, check the current module version and guidance rather than relying on a saved screenshot or blueprint.

• Some related records now return IDs. Retrieve the related record when you need its fields.
• Custom fields are grouped under custom_fields; check the mapped paths and value types.
• Use the documented underlying custom-field code. Renaming a display label does not necessarily break that mapping.
• Check the current search options and confirm an exact candidate match. The field names used by a custom API call may differ from the module interface.

Record the form payload contract, module version, field codes and acceptance date with your route. Re-run relevant cases after changes. These are documentation notes, not a claim that every rename breaks a workflow. Make’s Pipedrive documentation, checked 4 October and rechecked 5 October 2026.

Sources and method

• Pipedrive: avoiding duplicates during import
• Pipedrive: Merge Duplicates contact rules
• Make: Pipedrive connection, modules and version notes
• Make: webhook processing modes
• Make: incomplete executions
• Make: Retry error handler

Import and Retry-handler references were checked 3 October 2026. Pipedrive module and incomplete-execution guidance was checked 4 October and rechecked 5 October 2026; webhook and contact-merge guidance was checked 5 October 2026. The state model and cases are original implementation guidance. They do not report measured duplicate prevention or a successful product test.