TL;DR
- In enterprises, RevOps usually owns deduplication together with IT.
- RevOps knows the CRM and its links to sales, marketing and operations.
- IT covers the compliance, security and privacy side of a deduplication tool.
- An audit trail needs a merge history and a log of who changed what.
- Dedupely sets users, security policy and audit log per CRM, and records every merge.
In a small company, one admin decides what a duplicate is, runs the merge and answers for it. In an enterprise, the same merge touches sales territories, marketing lists, finance reports and integrations owned by other teams.
That's why deduplication at scale needs governance: clear owners, written rules, controlled access and a trail that shows what happened. Without it, every disputed merge turns into a search for who did it and why.
In this post, you'll see who usually owns deduplication in an enterprise and how to split the work. You'll also see what to write down, how to control access and what a useful audit trail records.
Why deduplication needs governance at enterprise scale
A merge changes shared records directly in the CRM. At enterprise scale, one rule can decide thousands of merges in a single run.
Many teams feel the result. Sales sees owners change, marketing sees lists shrink and finance sees customer counts move. Each of them will ask what changed, and someone needs to answer with facts.
Governance doesn't have to be heavy. It needs four things: an owner, written rules, controlled access and an audit trail.
Who owns deduplication: RevOps with IT
In enterprises, deduplication usually sits with RevOps, working together with IT. Each side brings what the other doesn't have.
RevOps owns the data and the rules
RevOps knows the CRM and how it connects to marketing, sales and operations. It knows which fields drive routing, reporting and integrations, so it's best placed to decide what a duplicate is and which values win.
IT owns compliance, security and privacy
IT's role is usually compliance. It reviews the tool that connects to the CRM: where data is processed, who can access it and how access is controlled. Our post on what security teams ask about a deduplication tool covers that review.
In some companies, IT also runs the deduplication itself. The split below still helps, since someone has to cover each task.
| Responsibility | Usually owned by |
|---|---|
| Definition of a duplicate, per object | RevOps, with input from sales and marketing |
| Which values win in a merge | RevOps, with the teams that use each field |
| Running merges and reviewing unclear sets | RevOps or the CRM admin team |
| Tool approval, access rules and security settings | IT |
| Privacy and compliance questions | IT, with legal or compliance |
| Periodic audit of merges and access | RevOps and IT together |
Write the rules down
Rules that live in one person's head don't survive a reorganization. Write them down where both teams can find them, and date every change.
- What counts as a duplicate, per object. What counts as a duplicate is case by case, so note the exceptions, like branches or subsidiaries that stay separate.
- Which values win. The surviving record, and the rule for owner, stage, email and any field an integration depends on.
- What merges automatically and what goes to review. Exact matches you're certain of can merge automatically on a schedule, while looser matches go to a person.
- Who approves a change. A new search or a changed rule affects every merge after it, so name who signs off.
Our Salesforce data governance guide includes a template for the wider data rules these sit in.
Control who can do what
In many deduplication tools, anyone with access can merge. Decide who needs that access, and keep the list short.
- Give admin rights only to the people who manage users and security settings.
- Require two-factor authentication and a password policy that matches your company's.
- Restrict access to known IP addresses if your security policy calls for it.
- Remove access the same day someone leaves the team.
If you run several CRMs, check whether access is set per CRM. A person who cleans one region's CRM may not need access to another's.
Keep an audit trail of every change
An audit trail answers two different questions, so it needs two different records.
| Record | Answers | What it should include |
|---|---|---|
| Merge history | What did this merge change? | The original records, the winning values, the result and a way to export them |
| Audit log | Who did what, and when? | Merges, including automatic ones, search and rule changes, logins, user and role changes |
The merge history lets you restore values if a merge went wrong. The audit log tells you whose rule caused it. Our post on why you need a record of every merge covers the first in detail.
Merge in controlled stages
Governance also shapes how merges run. Large cleanups go in stages, each one tested on a sample and checked before the next. Our post on running a big cleanup without disrupting sales shows how to plan them.
Agree on who signs off on each stage, and keep the decision with the audit trail. When someone asks months later why 4,000 accounts merged on a Tuesday, the answer is already written down.
Review the trail on a schedule, such as once a quarter. Look for merges nobody expected, rules that changed without approval and accounts that shouldn't have access anymore.
How Dedupely supports deduplication governance
Dedupely has two roles: admins manage users and company settings, and users can work with every other feature, including merging. Users, the security policy and the audit log are set per connected CRM, while billing and the record limit are shared. The security policy covers password rules, enforced two-factor authentication, closing inactive sessions and IP whitelisting.
The audit log records merges, including background merges, scans, search changes, invites, role changes and logins, and keeps entries indefinitely. Every merge also appears in the merge history with its original values, which you can export as a CSV.
Shared ownership, written rules, a full trail
Enterprise deduplication gets much harder when ownership is unclear. When nobody knows who decided a rule or ran a merge, every question becomes a dispute.
RevOps and IT sharing the work fixes most of that. RevOps decides what a duplicate is and which values win, and IT makes sure the tool and its access are safe. The audit trail shows both sides what happened.
Frequently asked questions
Who should own CRM deduplication in an enterprise?
Usually RevOps, working together with IT. RevOps knows the CRM and how it connects to sales, marketing and operations, so it defines duplicates and merge rules. IT covers compliance, security and privacy, including the review of any tool that connects to the CRM.
What should a deduplication audit trail include?
Two records: a merge history and an audit log. The merge history shows the original records, the winning values and the result of each merge, ideally exportable. The audit log shows who ran merges, changed searches or rules, logged in and changed user roles, with dates.
Who should approve CRM merges?
Approve the rules instead of every merge. A named owner, usually in RevOps, signs off on the definition of a duplicate, the merge rules and each large stage. Sets that don't fit the rules go to review by someone who knows the records, like the account owner.
How do you control who can merge records in a CRM?
Limit merge access to the people running the cleanup, and keep admin rights to those who manage users and security. Require two-factor authentication, apply your password policy and remove access when someone leaves. Check the audit log regularly for merges or changes nobody expected.
How often should you audit CRM deduplication?
Once a quarter works for many teams, plus a check after every large stage. Review merges nobody expected, rules or searches that changed without approval, and users who no longer need access. A large cleanup or a new integration is a good reason to audit sooner.
Or sign up with Google
