Merging Duplicate Records
Merging duplicate records is the step in deduplication where a set of duplicate records in a CRM becomes one record. One record survives as the primary record, merge rules decide which value each field keeps, and the activity, notes and associations from the other records move onto it before those records are removed.
Merging comes after matching. Matching decides which records describe the same person, company or deal; merging decides what the combined record looks like. That makes it the step where data is kept or lost. A careless merge can replace a current phone number with an old one, or a filled-in field with a blank. A well-planned merge keeps the best value in each field and the customer's full history in one place, so reports and teams see one complete record instead of several partial ones.
See how Dedupely decides what each merge keeps in your CRM
What Is Merging Duplicate Records?
Merging duplicate records is the process of combining a duplicate set into one record that keeps the useful data from each one. A simple example: two contacts for Jon Smith. The first was created years ago, has the work email jon@acme.com, a blank phone field and a long history of logged calls. The second came in last month from a form, with a personal email, the phone number (555) 010-2000 and a new job title. After the merge, one Jon Smith record remains. It holds the work email, the phone number and the new job title, and both the calls and the form submission sit on its timeline.
Records are merged within one object: contacts, companies, deals and tickets in HubSpot; accounts, contacts and leads in Salesforce; people, organizations and deals in Pipedrive; leads and opportunities in Close; and contacts in Nimble and Google Contacts.
There are a few ways to decide what the merged record keeps. Record-level merging keeps the primary record's values and fills its gaps from the others, which is simple and predictable. Field-level merging sets a rule for each field, such as the most recent value or the value from a trusted source, which gives more control over data that changes often. Merging by hand, field by field, gives full control over each value, which suits a few high-stakes sets.
How Merging Duplicate Records Works
Each merge makes the same few decisions, in roughly this order:
- Pick the primary record. This is the record that survives. Common choices are the oldest, the newest, the last updated, the one with the most field data, or custom criteria such as a lifecycle stage. In many CRMs the primary record keeps its ID; some, such as HubSpot, give the merged record a new ID, and the old IDs redirect.
- Choose the winning value for each field. Merge rules can keep the primary record's value, the most recent value, or the value from a specific source, and they can combine values in multi-value fields such as email addresses and phone numbers. Conditional rules can make a value win, or lose, when it meets a condition.
- Handle blank values. A blank field holds no information, so merge logic often treats it as missing and keeps the filled value. A rule that always keeps the primary record's value can carry a blank forward unless it falls back to the other records.
- Move activity, notes and associations. Activity such as calls, emails, tasks and notes, and associations such as linked companies, deals and contacts, move to the surviving record. Details vary by CRM: Salesforce reparents opportunities, tasks, cases and notes, while in HubSpot both records leave any active workflows.
- Remove the other records. Some CRMs keep them for a while, such as Salesforce's Recycle Bin for 15 days or Google Contacts' Trash for 30 days. Even so, a merge is often hard to reverse once the records are combined.
Why Merging Duplicate Records Matters for CRM Teams
Merging decides what the CRM shows after a cleanup. When the right values win, each customer has one current email, one owner and one lifecycle stage, and reports, routing and segments count them once. When the wrong values win, the cleanup itself creates bad data: an old email address replaces the current one, a deal goes back to a past owner, or a customer's stage moves backward. Those records then look clean, so the errors are harder to spot than the duplicates were.
What carries over matters as much as what wins. If activity, notes or associations stay behind on a removed record, the customer's history is split or lost, and the next person to open the record sees only part of it. Because many merges are hard to reverse, a mistake can stay in the CRM long after the merge.
Scale adds its own cost. Native merge tools are built for a few records at a time: Salesforce merges up to three records at once, Pipedrive merges duplicates one by one, and Nimble's merge takes two to five contacts. A large backlog of duplicate sets then means many separate merges, each one a chance for the wrong record to survive, while the extra records keep counting toward the bill in CRMs that charge by contact or record count.
Getting Started With Merging Duplicate Records
Decide what each merge keeps before you merge duplicates. Choose how the surviving record is picked and which value wins in each field, and check the fields that are often blank or out of date on one of the records. Merges are often hard to reverse, so the rules matter more than the speed.
Then preview a few merged records and start with the clearest sets, the ones matched on several strong fields. Merge those in bulk, check the results in the CRM, and leave very large or uncertain sets for a person to review.
Keep a record of what each merge changed. If a merge goes wrong, the original records and values are the quickest way to see what happened and put the right data back, field by field, or recreate a record if needed.
For records tied to billing, contracts or another system, merge by hand, one set at a time. A wrong merge there affects more than the CRM, so those sets are worth the extra minutes.
In Dedupely, Merge Rules decide which record survives and which value wins in each field, and blank fields never overwrite existing data. Merge History keeps each merge's original records and winning values.
Key Takeaways: Merging Duplicate Records
Merging duplicate records is the second stage of deduplication, where a duplicate set becomes one record. It picks the record that survives, decides which value wins in each field, keeps blank fields from replacing real data, and moves activity, notes and associations onto the surviving record. Because merges are often hard to reverse, the rules should be set and previewed before anything is merged. In Dedupely, the Primary Record and Merge Rules decide what each merge keeps, all activities and associations are preserved, and Bulk Merge handles the clear sets while Manual Review and Safety Settings hold back the uncertain ones. Merge History records every merge with the original records and winning values.
Frequently Asked Questions About Merging Duplicate Records
Can a merge be undone if the wrong records were merged?
Not in Dedupely. Because of how two-way CRM syncing works, a merge can't be undone. Some CRMs keep removed records for a short time, but the merged record has already changed, so restoring the original state often means rebuilding it. That's why the protection has to come before the merge: set the primary record and field rules first, preview the result, and review uncertain sets by hand. In Dedupely, Merge History shows every merge with the original records and the winning values, and it exports as a CSV with the original values of every merged record. If a merge goes wrong, you can use that file to recreate the records in your CRM, restore the original values by hand, and merge them again with corrected Merge Rules.
How do you decide which record survives when duplicates are merged?
Pick the rule that matches how your team uses the data. The oldest record often carries the longest history and the original ID, so it suits CRMs where other systems point to that ID. The newest or last updated record suits data that changes often. The record with the most field data keeps the fullest profile. Custom criteria, such as a lifecycle stage or an owner, suit teams with clear priorities. The surviving record doesn't have to keep all of its own values, since field rules can still pull better values from the other records. In Dedupely, the Primary Record can be the Oldest Record, Newest Record, Last Updated Record, Most Field Data or Custom, and the oldest Record ID is kept by default. HubSpot is the exception: it creates a new ID on every merge.
Which value should win when duplicate records disagree on a field?
It depends on the field, so set the rule one field at a time. For data that changes, like a job title, phone number or lifecycle stage, the most recent value is often the safest choice. For data entered by a trusted team or system, such as a billing address from finance, the value from that source should win. For fields that can hold several values, like email addresses, combining them keeps every working address. For fields where one value should always lose, such as a placeholder or a generic inbox, a rule can make it lose before any other rule runs. In Dedupely, Merge Rules offer Primary, "Best" options for fields such as email and phone, Append for multi-value fields, and Custom Win and Lose Rules. Lose Rules run before Win Rules, and Win Rules run from top to bottom.
How do you stop a merge from replacing a filled-in field with a blank?
Use merge logic that treats a blank as missing data, so a filled value always wins over an empty one. The risk comes from rules that copy the primary record's value without checking it: if the surviving record has an empty phone field, a strict "keep the primary" rule can keep the blank and drop the number from the other record. Check the fields that are often empty on newer records, such as phone, address and job title, and preview a few merged records before merging in bulk. In Dedupely, blank fields never overwrite existing data by default, and Merge Rules let you set field-level and Custom rules for the cases where you want more control. The in-line preview and the Preview Merge panel show the final values before anything changes in the CRM.
How do you merge duplicates in a CRM such as Salesforce, HubSpot or Pipedrive?
To merge duplicates in a CRM, pick the record that survives, decide which value each field keeps, check that activity and associations move over, and then merge. The same steps apply whether you merge duplicate contacts, companies or deals. Many CRMs have a native merge tool, but the details vary: Salesforce merges up to three records at once, Pipedrive merges duplicates one by one, and HubSpot gives the merged record a new ID. That works for a few sets. For a large backlog, a bulk merge applies the same primary record and field rules to many sets at once, so test the rules on a small batch, check the results in the CRM, and then merge the rest. In Dedupely, Bulk Merge can merge several sets, a whole page or every match in a search at once, and Auto Merge can merge new duplicates on a schedule using a Duplicate Search's criteria. Safety Settings move matches with more than 20 records to the Excluded tab, and Manual Review keeps uncertain sets for a person to check.
