How to merge thousands of Pipedrive duplicates in layers

To bulk merge duplicates in Pipedrive, you need a connected deduplication tool, because Pipedrive's own merge combines one pair of items at a time. A tool like that finds every set of duplicates with criteria you choose and merges many sets at once.

The tool is the easy part. A bulk merge changes hundreds or thousands of records in minutes, and Pipedrive merges can't be un-merged. The plan decides whether it goes well: which items you merge first, what happens to archived items and how you test first.

In this post, you'll see how to plan a bulk merge item type by item type. You'll also see how to run it in layers, so the first big merge is also a safe one.

What Pipedrive's own merge covers

Pipedrive lists possible duplicate people and organizations under Merge Duplicates. You pick the primary item, preview the result and confirm, one pair at a time. Its merge help pages describe this for people, organizations and deals, and say merged duplicates can't be un-merged.

As of October 2026, from Pipedrive's support center: Merge duplicates and Updating items in the detail view.

For a handful of duplicates, that's enough. What Pipedrive suggests as a duplicate, and where its merge stops, is covered in Pipedrive duplicates and where native merging stops.

What bulk merging means

Duplicates don't always come in pairs. One person can exist three or four times after a few imports, and one organization can exist five times after a migration. A set of records that belong together is a match.

Bulk merging has two parts. Every record in a match merges into one in a single action, and many matches merge at once with the same rules. Pair by pair, a match of four records takes three separate merges, and each one asks you to choose the primary item again.

Plan the order: organizations first

In Pipedrive, people, deals and leads hang off organizations. When two duplicate organizations merge, their links come together. An organization with three people and its duplicate with two become one organization with five.

That's why the order matters. Many teams start with organizations because of the domino effect:

1. Organizations. Merging them first puts the people and deals of one company under one record.
2. People. Duplicate people inside one organization are now easier to spot and to confirm.
3. Deals and leads. Once the people and organizations are merged, the same deal logged twice sits side by side.
4. Products. The catalog is separate from your contacts, so it can go last or run on its own.

What counts as a duplicate is case by case at every step. Two organizations with one name and different addresses can be branches your team wants to keep apart.

Decide what to do with archived deals and leads

Pipedrive's help center lists merging among the actions archived deals can't take, and archived leads can't be merged either. Old lost deals and leads are often where duplicates sit, so decide what to do with them before you start.

• Leave them archived. If nobody reports on them, they can stay as they are and stay out of the merge.
• Unarchive the ones that matter. Pipedrive lets you select several items in the archived list view and unarchive them together. A deal whose pipeline or stage no longer exists won't show in any pipeline until you assign one.

As of October 2026, from Pipedrive's support center: Archive deals and leads.

Agree with sales on which archived items still matter for reporting before you change their status.

Products need their own pass

Product catalogs duplicate in a different way. An import adds a product that already exists, or two people add the same item with a slightly different name. Pipedrive's merge help pages don't describe merging products, so these duplicates tend to stay put.

Match products on what identifies them in your catalog, like a product code or SKU field if you use one, plus the name. Check the price and any variations before merging, since two items with one name can be two sizes or two plans.

Merge in layers, from certain to uncertain

A bulk merge is only as good as the criteria behind it. Start where you're certain, then widen.

Layer 1: exact matches

People with the same email and the same name, and organizations with the same website domain and name. You might not get loads of them, but they build confidence in bulk merging quickly.

Layer 2: near matches

Names with typos or nicknames, phone numbers in different formats and company names with or without "Inc.". These need a closer look at a sample before you merge them in bulk.

Layer 3: review

Sets with different owners, organizations that share an address and people who share a phone. Send them to a person who knows the accounts. Some teams bulk merge sets with the same owner and keep different-owner sets for later.

Test each layer

Before selecting everything, merge one or two sets by hand and open the result in Pipedrive. Then merge one page and check a sample. Reject every false match you find so it stays out of later runs.

Treat every merge as permanent, and keep a record of the original values before a large merge. What each part of a record keeps after a merge is covered in what happens when you merge in Dedupely for Pipedrive.

After the backlog: keep up with new duplicates

Forms, imports and connected apps keep creating new duplicates after the cleanup. Once a search has proven itself, you can merge new duplicates you're certain of, like exact email matches, automatically on a schedule. Looser searches can send an alert instead, so a person checks them first.

For very large accounts, the same approach scales with a few extra steps, covered in how to deduplicate a large CRM database.

A bulk merge is a plan, then a click

Pipedrive's own merge is built for the occasional pair. A backlog of hundreds or thousands of duplicates needs a tool that merges whole matches at once, and a plan for using it.

Start with organizations, decide what happens to archived items, give products their own pass and merge in layers from exact to uncertain. Test each layer on a few sets first. Then the big merge is the last and least risky step.

Frequently asked questions