Pipedrive import duplicates: people, organizations and repeat deals

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Different objects need different identity rules

Pipedrive's import duplicate guide does not treat every identical title as one record. It documents contact matching using names and additional identifiers, organization matching with address information, and no duplicate identifier for deals based on their names. Two imported deals with the same title can both be created. Review the merge choice rather than assuming an import is universally repeat-safe.

Our recommendation is an identity policy per object. Decide whether a row represents a person you already know, a distinct location of an organization, or a new sales opportunity with an existing customer. A repeated customer is not automatically a repeated deal.

A fictional identity worksheet

The policy should follow the business model. Do not change a person's name or invent an address solely to force a technical match. Ambiguous identity needs review before a merge changes real records.

Build a safe sample

1. Create a synthetic dataset with an exact repeat, a same-name namesake and an existing customer with a second opportunity.
2. List expected distinct people, organizations and opportunities.
3. Include stable source references and genuine disambiguating fields where available.
4. Inspect the import's duplicate handling options before completion.
5. Compare actual destination identities and relationships with the expected list.

Do not confuse merge with verification

Our recommendation is to inspect the resulting combined record whenever a merge is expected. Check that phone numbers, email addresses and organization relationships still belong to the intended person. One contact instead of two is not success if the surviving record combines two different individuals.

Also inspect conflict handling: if the source and existing CRM disagree, decide which system is authoritative for that field. A new telephone number may be a useful addition, an outdated value or a different person's number. The platform cannot infer the business truth from your migration intent.

Make repeat imports an explicit procedure

Suppose a fictional file contains five opportunities. If one row needs correction after the first import, do not assume uploading all five again will merely update them because titles match. Retain the source-to-destination ID mapping and choose a supported update method or a narrowly scoped recovery import.

A custom source reference helps reconciliation but should not be assumed to create an automatic uniqueness constraint. Verify the actual update or matching mechanism used by your import. For integrations that write repeatedly, choose a documented lookup and update contract instead of title matching alone.

Acceptance criteria

Accept the identity policy when namesakes remain separate, expected repeats reconcile to the right contacts and genuine repeat business remains separate opportunities. Document ambiguous rows and their owner. This article supplies a hypothetical validation dataset and operational recommendations; it does not claim a live duplicate-cleanup test or that a single matching field establishes identity in every account.