Native Deduplication
Native deduplication is the duplicate management built into a CRM itself: the checks that flag a possible duplicate when a record is created, the lists of suspected duplicates, and the merge screen used to combine them. The term also covers CRM merge limits, the rules that set how many records a built-in merge can take, which objects it covers and what happens to the records it combines.
Built-in duplicate tools differ from one CRM to the next, but they often share the same shape. Detection often compares a few fields, such as email address for contacts or domain for companies, and looks for values that are the same. Merging is often built for one person comparing a few records side by side and choosing what to keep. Knowing which fields a CRM checks and where its merge stops shows which duplicates it handles well and which ones need another approach.
See how Dedupely works alongside native deduplication in your CRM
What Is Native Deduplication?
Native deduplication is the set of duplicate tools a CRM ships with, and it applies to the objects that CRM stores: contacts and companies in HubSpot, accounts, contacts and leads in Salesforce, people and organizations in Pipedrive, leads in Close, and contacts in Nimble and Google Contacts. Built-in duplicate tools often combine a few approaches.
Entry checks look at a new record as it's created and warn about, flag or stop a likely duplicate. Their strength is timing: they catch the duplicate at the moment someone types it, before anyone works the record. Suggested duplicate lists compare existing records and show likely pairs. Their strength is that they need little setup and surface duplicates that are already in the CRM. Manual merge screens put a few records side by side and let a person pick the surviving record and the values to keep. Their strength is control over each value in each merge.
Take a contact a rep adds as "Sean Murphy, sean.murphy@acme.com," and a form fill a month later from "Shawn Murphy, smurphy@gmail.com," same company, same phone number. A check that compares email addresses sees two different values and lets both records in. The two records describe one person, but nothing in the built-in check connects them.
That's the line native deduplication draws: it handles duplicates that agree on the fields it checks, and it merges them within the limits its CRM sets.
How Native Deduplication Works
Native deduplication runs in two stages, detection and merging, and each stage has its own limits.
- Check new records. When a record is created by hand, through a form or by an import, the CRM compares it with existing records on the fields it watches. The result can be a warning, a flag on the record or a blocked save, depending on the CRM and the settings.
- Compare the chosen fields. Built-in checks often compare a few fields, and many look for the same value. Records that differ by a typo, a nickname, a second email address or a phone number in another format often get through.
- List suspected duplicates. Some CRMs also show pairs among existing records, so a person can open them and decide what to do.
- Merge a few records. A person picks the surviving record and the values to keep, and the CRM combines the records. How many records one merge can take varies: Salesforce's native merge stops at three records, Pipedrive merges one by one, and Nimble's native merge takes two to five.
- Apply the CRM's merge limits. Each CRM has its own rules about what a merge can do. Pipedrive's own merge doesn't cover Products. HubSpot creates a new record ID on every merge, caps how many associations one record can have, and limits how many times a record can be merged. Salesforce sends the secondary records to its Recycle Bin for 15 days. Close's API has no contact merge.
Together, these limits decide how far the built-in tools go before a cleanup has to be done another way.
Why Native Deduplication Matters for CRM Teams
Native deduplication sets the baseline for how clean a CRM stays on its own. The duplicates it catches never become a cleanup job. The ones it misses stay in the CRM, and they keep affecting the data: contact and account counts run high, pipeline reports count the same customer more than once, activity history splits across records, and two reps can work the same lead. In CRMs that bill by contact or record count, each missed duplicate is also a record the company pays for twice.
CRM merge limits shape the cost of fixing those misses. When a merge takes a few records at a time, a backlog of hundreds of duplicate sets becomes hundreds of separate merges, each with its own choices about which record survives and which value wins. Different people make different choices, so the merged records don't follow one logic.
Merge limits also affect what happens after a merge. A new record ID matters to reports and other systems that reference the old one, a cap on associations can decide which linked records stay connected, and a record that has been merged many times can reach a limit. Knowing these limits in advance lets a team plan a cleanup that works within them instead of running into them partway.
Getting Started With Native Deduplication
Start by finding out what your CRM's built-in duplicate tools check. Note which objects they cover, which fields they compare, whether they warn, flag or block, and whether they look at imports and syncs as well as records added by hand. The CRM's own documentation is the place to confirm the details.
Then look for what gets through. Run a search on fields the built-in check doesn't compare, such as name plus company or phone number, and on looser comparisons that catch typos and formatting differences. The sets it finds show the size of the gap and which patterns cause it.
Plan around the merge limits next. Count how many records your largest sets hold, check which objects the native merge covers, and find out what a merge does to record IDs, associations and linked systems. Keep the built-in entry checks on, since they stop some duplicates before they exist, and use a dedicated approach for the sets they miss and the merges they can't take.
In Dedupely, Duplicate Searches cover the fields native checks often skip, with a Match Option for each field, such as Similar for typos and phone formats or Fuzzy for names that sound alike. Bulk Merge then merges many duplicate sets in one action, with the Primary Record and Merge Rules you've set applied to each one.
Key Takeaways: Native Deduplication
Native deduplication is the duplicate checking and merging built into a CRM. Its entry checks stop some duplicates as they're created, but they often compare a few fields, so records that differ by a typo, a nickname or a second email get through. Its merge limits, such as Salesforce's three records per merge or HubSpot's new ID on every merge, make large cleanups slow. In Dedupely, Duplicate Searches give each field its own Match Option, Bulk Merge merges many sets at once, and Merge Rules and the Primary Record decide what each merge keeps. Safety Settings set standing answers for HubSpot's association and merge limits, and Auto Match and Auto Merge keep trusted searches running as new records arrive.
Frequently Asked Questions About Native Deduplication
Does a CRM such as HubSpot or Salesforce detect duplicates automatically?
Many CRMs detect some duplicates automatically, but what they check differs from one CRM to the next. Built-in detection often compares a few fields, such as email address for contacts or domain for companies, and looks for values that are the same. That catches a person who signs up twice with the same email, but not one who uses a work email once and a personal email the next time. Imports, syncs and other connected tools add records too, and a check may treat them differently from records added by hand. The CRM's own documentation is the place to confirm what yours checks. In Dedupely, new records are detected within 1–5 minutes and compared in Duplicate Searches, where each field gets its own Match Option. Auto Match notifies you when new matches reach a count you set, and Auto Merge can run as soon as possible to merge new duplicates on a search you trust.
What are CRM merge limits, and how do you work within them?
CRM merge limits are the rules a CRM sets on its own merge: how many records one merge can take, which objects it covers and what happens to the records afterward. Salesforce's native merge stops at three records, Nimble's takes two to five, and Pipedrive merges one by one and doesn't cover Products. Other limits apply to the records themselves: HubSpot creates a new record ID on every merge, caps how many associations a record can have and limits how many times a record can be merged. Working within these limits means splitting large sets, checking associations before merging and updating any system that stores the old record ID. In Dedupely, for HubSpot, Safety Settings let you set standing answers: when a record has too many associations, always ask, merge and keep the associations that fit, or skip; when it has too many past merges, always ask, merge by copying the data over, or skip. Auto Merge can't ask, so it skips matches set to always ask.
Why do built-in duplicate rules miss some duplicates?
Built-in duplicate rules miss duplicates that don't agree on the fields they check. A rule on email address doesn't connect a contact saved with a work email and the same person saved with a personal one. A rule that looks for the same value misses "Acme Inc" and "Acme, Inc.", a phone number saved with and without a country code, and names like "Sean" and "Shawn." Values entered in the wrong field, such as a company name in the last name field, often get past simple checks. Records from imports and syncs can also arrive in formats a rule doesn't expect. In Dedupely, each field in a Duplicate Search gets its own Match Option: Exact, Similar, Fuzzy, Similar Words or Domain Root. Similar catches minor typos and strips formatting from phone numbers, and Fuzzy catches alternate spellings. Cross-field matching finds misplaced values in other fields used in the match, and Typo allowance keeps small differences from blocking a match.
When is native deduplication enough for a CRM?
Native deduplication can be enough when a CRM has few entry points, duplicates tend to agree on the fields the built-in check compares, and merges are occasional enough to handle a few records at a time. A small team adding contacts by hand, with one form and no syncs, may find that its CRM's own tools keep up. It stops being enough when records arrive from imports, enrichment tools or syncs between systems, when duplicates differ by typos or second email addresses, or when a backlog of sets is larger than anyone can merge one by one. One way to tell is to run a broader search and see how much the built-in check missed. In Dedupely, preset Duplicate Searches are ready the first time you log in, and connecting or syncing a CRM never merges, edits or deletes anything. The results show what the native tools let through before any decision is made.
How do native deduplication tools and a dedicated deduplication tool work together?
Native deduplication tools and a dedicated tool work together when each handles the part it does best. The built-in entry checks stay on and stop some duplicates as they're created. The dedicated tool finds the duplicates that get through, on more fields and with looser comparisons, and merges them in larger batches under saved rules. Both work through the same CRM, so a merge follows that CRM's own behavior, such as a new record ID in HubSpot. In Dedupely, merges happen only when you say so, and connecting or syncing never changes CRM data. Without Merge Rules, Dedupely follows the CRM's own merge logic, and blank values never win a merge. All activities and associations are preserved, and with an active HubSpot–Salesforce integration, Dedupely merges the duplicates in both CRMs at once. Dedupely matches and merges within one object, so a Lead isn't merged with a Contact.
