Pomio CRM keeps contacts, companies and deals in one shared workspace, so a duplicate is never just one person’s problem. Two records for the same customer split the activity history, show two owners and can make the same opportunity look like two. Merging fixes that, but only when the right person merges the right records in the right direction. Who may merge is therefore as important a question as how duplicates are found in the first place.
Why a merge is riskier than it looks
Finding duplicates is a search; merging them is a decision. When two records become one, notes, activities, deals and contact details from both end up in a single place, and some field values are overwritten. Merge the wrong pair, such as two different people with the same name at two different customers, and you mix two histories that are very hard to separate again. Merge in the wrong direction and the record with years of activity disappears behind a newer, emptier one. Unlike archiving instead of deleting, a merge rarely has a simple way back, so it deserves the same care as a deletion.
A practical default: your own records yes, a colleague’s records no
For most sales teams of five to fifty people, three levels work. A salesperson may merge obvious duplicates when both records are their own, for example the same contact entered twice with a typo in the name. When one of the records belongs to a colleague or to another team, the merge goes to the sales manager, who can see both records and talk to both owners. Large clean-ups across the whole organisation, typically after an import, belong to one named person with manager or administrator rights. That mirrors the own, team and organisation scope people already work with, and it keeps administrator rights for users and settings, as described in how many administrators a small business CRM should have.
Agree which record survives
Write down a short survivor rule so that every merge goes in the same direction. A common choice: keep the record with the most history or the one linked to open deals, and copy over the newest verified details, such as a changed phone number or email address. The owner of the surviving record is the person who actively manages the relationship, in line with every contact having one owner. For companies, decide once whether a record carries the legal name or the trading name, as explained in legal name versus trading name, so a merge does not quietly rename a customer.
When not to merge
Some apparent duplicates are not duplicates at all. Two people who share one general mailbox are still two contacts. A contact who moved to a new employer is a new relationship, not a copy of the old one; the approach in archiving or moving a contact who leaves a customer applies. Subsidiaries and branches that are invoiced separately are separate companies, even when their names are almost identical. When in doubt, do not merge: add a note to both records, ask the owners and decide in the next review. A wrong merge costs far more time than a duplicate that lives a week longer.
Talk to the owners first
A merge changes what owners see in their own lists. Deals may move to another record, activities appear in a different timeline and one owner may lose a contact altogether. Tell both owners before a merge that crosses ownership, and agree who keeps the relationship. When the customer has open deals, check afterwards that each deal still has one clear owner, so the pipeline does not change without anyone noticing.
Leave a trail and prevent the next duplicate
Add a short note to the surviving record: what was merged, why and by whom. Before a bulk clean-up, take a snapshot with a CSV export of contacts and companies, and rely on an audit trail of who changed what when a merge is questioned later. Then fix the source: most duplicates arrive with imports, so check every import for duplicates first and pick up the rest in a monthly data-quality check.
How Pomio CRM helps
Pomio CRM has four roles: sales rep, sales manager, viewer and organisation admin. Each permission carries a scope, own, team or organisation, which is enforced on the server, so the people who clean up records only reach the records within their scope. Every contact, company and deal has an owner, contacts and deals are linked to companies, and records can be archived and restored with their relationships intact. The audit log shows who did what and when, without passwords or multi-factor secrets. An overview of the capabilities is on the features page.
A practical checklist
Let salespeople merge obvious duplicates only when both records are their own; send merges across owners or teams to the sales manager; give organisation-wide clean-ups to one named person; write down which record survives; keep the record with the most history and copy over the newest verified details; agree the company name rule before merging companies; never merge two people, two employers or two legal entities; tell both owners before a merge that crosses ownership; check deal ownership afterwards; add a note to the surviving record; take a CSV export before bulk clean-ups; check imports for duplicates and review the rest every month.
Further reading
Should duplicates be merged automatically?
Only on exact matches, such as the same email address, and even then with a check of what gets overwritten. Records that merely look alike belong in a review list for a person to decide.
What if two owners both claim the customer?
The sales manager decides, based on who has the active relationship and the open deals. Record the decision in a note on the surviving record.
Should a read-only user be able to merge records?
No. A read-only role is for looking at figures, not for changing records, and a merge changes two records at once.
Is archiving the duplicate an alternative to merging?
Sometimes. If the duplicate has no history worth keeping, archiving it is simpler and reversible. If both records carry history, merging keeps that history together.