Duplicate management is an identity workflow. Gather records that might describe the same person or account, test the match, choose which record should carry the history, and merge only after conflicts are clear. The difficult part sits between systems: a CRM and an email platform can use the word "contact" for different entities, so a merge can make a subtle mistake that goes unnoticed for a month.1 Treat every match as a decision about identity and history. The goal is a clean record that still explains the conversations, account context, and related work attached to it.
Set the scope
Start with the records that can collide, then make the input comparable before you search. That gives the review a defined boundary and keeps an outside list from entering the CRM as an unexamined second copy.
Duplicate records enter through manual entry and bulk import.2 If a prospecting list is online, ask for a CSV so it can be deduplicated against the CRM.3 When an account already exists, carry its name into the CSV.4 Check that the accounts in the file match existing accounts.5
Before running a merge, decide what the record represents in each system. For every candidate, keep the source list and CRM record visible so you can compare identity, account context, and existing activity.
Run candidate detection
| Bulk duplicate search | Local duplicate search |
|---|---|
| Entire database | New record |
| On a schedule | Automatically |
Use detection to build a review queue. The search finds possible matches, and the merge decision comes later.
A bulk duplicate search can cover the entire database manually or on a schedule.6 A local duplicate search can run automatically for a new record when it is saved.7 Use the local check at the point of entry and the bulk search for records already in the database.
Keep a manual route for cases the search misses. You can merge a duplicate without running a search,8 and that option is available across all sections.9
Allow for variation in the search. Different email addresses and slight spelling changes can still describe the same person.10 Treat an exact match as a strong signal, then inspect the surrounding record before merging.
Verify the candidate
Search output is a queue for judgment. Open each candidate and decide whether the records describe the same person or account in the same data model.
Use these questions while reviewing:
- Does the email belong to the same person?
- Does the account context match?
- Does the activity history belong to the same relationship?
- Which fields disagree, and can you explain the difference?
Where the CRM supports field matching, select Email Address from each object as a matching criterion.11 Then compare the result with the account and activity context. A match that looks clean in one field can still represent separate records, especially when the records came from different systems.
Move to the merge decision when the identity and destination record are clear. Leave the candidate open for review when you cannot explain the difference between the records.
Choose the master
Keep the choice of master separate from candidate detection so a plausible match does not silently choose the destination. If your merge flow keeps the current page as the master, open the record you intend to keep before selecting the duplicate. The selected record is then combined into the record you are viewing.12
Resolve field conflicts during consolidation.13 Review the values that matter to outbound work, including contact details, account relationship, ownership history, and activity. Before confirming, inspect whether the candidate has related or child records, because merging a record also merges those related records.14
Confirm and check the result
After the merge, open the surviving record and check the fields and activity that drove the decision.
Duplicates split conversation history, fragment account information, and create reporting problems that worsen over time.15 Check that the surviving record contains the history you expected, the account information is still coherent, and the record appears correctly in reporting. If any of those checks fail, stop further merges and investigate the merge result before processing another candidate.
Prevent recurrence
Cleanup works best when the next record faces a duplicate check at entry. Put the prevention rule on the fields that should identify a unique person or account.
Use a "Do Not Allow Duplicates" setting on unique fields such as email address and phone number where your CRM offers it.16 When enabled, the setting prevents another record with the same email address or phone number.17
Add duplicate-detection rules for other situations your CRM can recognise.18 Keep the rule set close to the way records enter the system, including manual entry and imports, so the same matching logic applies across both paths.
What not to do
These mistakes turn a review queue into a data-loss exercise. Keep them in front of anyone who can approve a merge.
- Do not treat a same-name match as proof of duplication. A user can still be unsure whether the record is new or a duplicate.19
- Do not merge every suggested match without reviewing it. Review each candidate and choose whether to merge or skip it individually.20
- Do not assume a mistaken merge is easy to reverse. Recovery of lost progress may require the platform's account or customer support route.21