Why Pipedrive doesn't stop this on its own
Some CRMs enforce duplicate prevention at the platform level — Salesforce, for example, has a dedicated Duplicate Rules and Matching Rules feature that can block or warn on likely-duplicate records automatically. Pipedrive has no equivalent for Deals. A Deal record has a title, an associated person_id and/or organization_id, a value, and a pipeline stage — none of these are enforced as unique, and there's no server-side matching logic running behind the Deals API.
This means the responsibility for preventing duplicate deals sits entirely with whatever creates them. A typical failure pattern: a lead-capture form triggers an n8n workflow that creates a Pipedrive deal for that person, and the same person submits the form again a week later (following up, or just clicking submit twice) — the workflow fires again and creates a second, completely separate deal for the same person with no warning.
The fix: search for an open deal first, branch, then create or update
Use Pipedrive's Search Deals endpoint (available via the n8n Pipedrive node's Search operation, or a direct HTTP Request node call) to look for an existing open deal tied to the same person or organization before ever reaching the Create step. Filter to open deals only — status: open — so that a previously Won or Lost deal for the same contact doesn't block a legitimate new deal from being created.
- Pipedrive node → Search: search term the person's identifying value (email, or name if that's your only reliable field), filtered by person_id or organization_id if you already have it from an earlier step.
- Add a status filter for open deals only — a person with a Won deal from six months ago should still be able to get a brand-new deal today.
- IF node: branch on whether the search returned any open deal.
- True branch (open deal already exists): either stop the workflow (no duplicate created) or Update the existing deal (e.g. bump its value, add a note) depending on your process.
- False branch (no open deal found): proceed to Create, exactly as the workflow did before.
GET https://yourcompany.pipedrive.com/api/v2/deals/search?term={{ $json.email }}&fields=title,notes&person_id={{ $json.pipedrivePersonId }}&status=open&exact_match=false
x-api-token: {{your_api_token}}
# Returns 0 or more matching open deals for this person —
# branch on whether the result set is empty before creating.Match on person/organization ID, not on deal title text
Avoid matching purely on the deal's title string ("John Smith - Website Inquiry") since two genuinely different deals for the same person can easily share similar wording, and a title generated by a template will always match itself on a second run even when a brand-new legitimate deal is warranted. Matching on the linked person_id or organization_id combined with an open-status filter is much more reliable — if you don't already have the Pipedrive person_id at this point in the workflow, add a Search Persons (or Find/Create Person) step ahead of the deal search so you're filtering by a real ID, not a name string prone to typos and formatting differences.
If your business process genuinely allows multiple concurrent open deals per person (for example, a company that sells several distinct products to the same client at once), narrow the search further by also matching on a specific field that identifies the deal type or product line, rather than blocking all creates for that person outright.
One gap this pattern doesn't fully close: near-simultaneous triggers
If the same trigger can fire twice within a few seconds of itself (a double-submitted form, or a webhook that Pipedrive or another system occasionally retries), the search-then-create pattern above has a small race-condition window: both executions can run their search before either one's create has completed, and both find "no existing deal." For high-volume workflows where this matters, consider adding a short delay before the search on retriggerable paths, or a secondary check (e.g. a lightweight external lock, or deduplicating on your own idempotency key such as the form submission ID) rather than relying on the search-before-create pattern alone to close every possible timing gap.
Sources checked for this guide
Pipedrive's Deals Search endpoint (parameters, cost, and the fields it can filter on) is documented in Pipedrive's own API v2 reference. The lack of a native duplicate-deal safeguard, and the search-and-filter approach as the practical workaround, are consistent with an n8n Community discussion about finding a specific deal for a person before acting on it.
