Merge History
Merge history is a log of the merges made in a CRM or deduplication tool, showing which records were combined, when each merge happened, and the values every original record held before it. It turns each merge from a one-way change into something a team can look up, check and explain later.
Merge history is also where teams turn when they want to undo a merge. Some CRMs can't unmerge records, and others keep the removed records only for a limited time, and the surviving record has already changed. A merge log keeps the original records and values, so a wrong merge can be traced and repaired by hand: the removed records recreated, the right values put back, and the set merged again with better rules.
See how Dedupely keeps a record of each merge in your CRM
What Is Merge History?
Merge history, also called a merge log or merged record history, is the written trail a merge leaves behind. Take two contacts from Acme. The first is J. Smith, jsmith@acme.com, phone (555) 010-2000, owned by Dana. The second is J. Smith, j.smith@acme.com, with a blank phone field and the job title "VP Sales." After the merge, one record remains. The merge history entry shows the date, both original records with every field value, and the merged result. If it later turns out the second record was a different person, that entry is what lets the team rebuild it with its original values.
Merges happen on every kind of object: contacts and companies in HubSpot, accounts and leads in Salesforce, people and organizations in Pipedrive, leads in Close, and contacts in Nimble and Google Contacts. A useful history covers each object it merges.
There are a few ways to keep it. A per-record history, such as a note on the surviving record's timeline, shows the merge in context, where people already look. A central merge log lists every merge in one place, searchable by object and date, which suits reviewing a whole cleanup and exporting the results. An audit log records who did what across the system, which suits accountability and access reviews. Many teams use more than one, because each answers a different question.
How Merge History Works
A merge history follows each merge from start to finish:
- Capture the records before the merge. Each original record's ID and field values are saved before anything changes, including the values that won't survive. This snapshot is the part that makes a repair possible later.
- Record the merge. The entry notes the date, the records that went into the merge and the result, often with a link to the merged record. A link helps because IDs can change: HubSpot, for example, gives the merged record a new ID, and the old IDs redirect.
- Make it searchable. Entries can be grouped by object and filtered by record or date range, so one merge, or every merge from one cleanup, can be found later.
- Export it. A download, such as a CSV of the original values, supports audits, side-by-side checks in a spreadsheet and rebuilding records in the CRM.
- Restore by hand when needed. A merge changes the surviving record, moves activity and associations, and removes the other records. Some CRMs keep removed records for a while, such as Salesforce's Recycle Bin for 15 days or Google Contacts' Trash for 30 days, but the surviving record still holds the merged values. Repairing a wrong merge means recreating the removed records, putting their values back from the history and merging the set again with corrected rules.
Why Merge History Matters for CRM Teams
A wrong merge is hard to see. Two customers' emails, phone numbers, owners and activity end up on one record that looks complete, so reports count one customer instead of two, a rep calls the wrong person, and an invoice or renewal reaches the wrong contact. Some CRMs can't undo a merge, so the error stays until someone repairs it by hand. Without a history, nobody can say what the records looked like before the merge, and the fix depends on memory, old exports or backups.
A merge history changes the size of the problem. With the original values on file, a team can find the exact merge, see which values replaced which, and rebuild the record that was lost. It can also scope a mistake: filter by date or object to find every merge from a faulty rule or a scheduled run, instead of guessing which records were affected.
It matters more as merging scales. Bulk and scheduled merges change many records at once, and a CRM synced with other systems passes those changes along. A clear log of what changed, and a separate record of who ran it, lets teams merge at that scale and still answer questions about any record later, such as where a value came from or why two records became one.
Getting Started With Merge History
Check how merges are logged before you merge in bulk. Look for a history that keeps each original record with all of its values, not only the result, and that can be filtered by object and date and exported as a file. If the log only shows the surviving record, a wrong merge can't be repaired from it.
Review the history after the first runs of a new merge rule or a scheduled merge. Open a handful of entries, compare the original values with the result in the CRM, and fix the rule before it runs on more sets. After a large cleanup, export the history and keep the file with the project's other records.
When a merge goes wrong, start from the history entry, not from memory. Export the original values, recreate the removed records, put the right values back, correct the rule that caused the problem, and merge the set again. For questions about who ran a merge, keep an audit log that only the people responsible for the CRM can open.
In Dedupely, Merge History carries out this approach: it records each merge made in Dedupely, per object, with every original record and its values, a link to the record in the CRM and a CSV download. Since merges can't be undone, that CSV is how you recreate the records and restore their values by hand, while the Audit Log, open to admins, shows who ran each merge.
Key Takeaways: Merge History
Merge history is the log of past merges: which records were combined, when, and the values each one held before the merge. Because some CRMs can't unmerge records, and others keep removed records only for a limited time, it's the way to trace a wrong merge and repair it by hand by recreating the records, restoring their values and merging again with better rules. A useful history keeps every original value, can be searched by object and date, and exports as a file. In Dedupely, merges can't be undone, and Merge History keeps each merge's date and original records with their values, links to the record in the CRM and downloads as a CSV. The Audit Log, for admins, shows who ran each merge.
Frequently Asked Questions About Merge History
Can you undo a merge in a CRM such as HubSpot or Salesforce?
Often not in the way people expect: some CRMs can't unmerge records, and those that keep the removed records do so only for a limited time. Salesforce, for example, moves the secondary records to the Recycle Bin for 15 days, and Google Contacts keeps deleted duplicates in Trash for 30 days. HubSpot gives the merged record a new ID, and the old IDs redirect to it. Even when a removed record can be brought back, the surviving record keeps the merged values and the activity that moved onto it, so a full reversal takes work by hand. The CRM's own documentation is the place to confirm what yours allows. In Dedupely, a merge can't be undone, because of how two-way CRM syncing works. Merge History keeps the original records and their values, so you can export them as a CSV, recreate the records in your CRM, restore the values by hand and merge again with corrected Merge Rules.
How do you restore a record after a wrong merge?
Rebuild it from the original values in the merge history. Find the merge entry, by record name or by the date it happened, and export or note the original values of every record in it. Recreate the removed record in the CRM with those values, then correct the surviving record so it holds only its own data again. Check the associations and activity on both records, because a merge moves them onto the survivor. Before merging the set again, fix the cause: the match that paired the wrong records, or the rule that picked the wrong values. In Dedupely, merges can't be undone, so this is the recovery path. Merge History shows each merge with every original record and its values, and its CSV download holds the original values of every merged record. Use it to recreate the records in your CRM, restore the values by hand and merge them again with corrected Merge Rules.
How can you see who merged a record in a CRM?
Check the audit log, the record of who did what in the system. A merge history answers what changed, such as which records were combined and which values they held, while an audit log answers who made the change and when. Some tools keep both in one place, and others keep them apart, with the audit log limited to admins. If several tools can merge records in the same CRM, check the log of each one, since a merge only shows up in the log of the tool that ran it. In Dedupely, Merge History shows what was merged, not who merged it. Who ran a merge is in the Audit Log, which only admins can open. It records merges, including background merges, along with scans and Duplicate Search changes. Each entry shows the user, the date and time and a description, and the log can be filtered by date.
What should a merge log record for each merge?
A merge log should record enough to rebuild every record that went into the merge. That means the date of the merge, the object, each original record's ID and all of its field values, the record that survived, the values that won and the merged result. A link to the merged record helps, because some CRMs change the ID on a merge. The log should be searchable by record and date range, show how many merges were made, and export as a file for audits and repairs. Who ran the merge belongs in the log or in a linked audit log. In Dedupely, Merge History is kept per object and can be searched and filtered by date range. It shows the total number of merges, each merge's date and every original record with its values, links to the record in the CRM and downloads as a CSV. Who merged each record is in the Audit Log, for admins.
How do you export merge history from a deduplication tool?
Download it as a file, such as a CSV, from the tool that ran the merges. If the tool lets you filter the history first, by object or date range, the file can cover only the cleanup or scheduled run you need. A useful export holds the original values of every merged record, not only the result, so it can be used to check merges in a spreadsheet, answer audit questions or recreate records in the CRM after a wrong merge. Keep the file with the project's other records, and export again after each large cleanup, so the original values are also kept outside the tool. In Dedupely, Merge History downloads as a CSV with the original values of every merged record. You can search it and filter it by date range, and each object has its own history. Because merges can't be undone, that CSV is also the starting point for restoring records by hand.
