# How to build a deduplication system for RevOps | Dedupely > A deduplication system runs without heroics: a search per source, shared merge rules, alerts, scheduled merges, review by owner and a log of every merge. - URL: https://dedupe.ly/blog/deduplication-system-revops - Section: blog - Published: 2026-10-22 - Site index: https://dedupe.ly/llms.txt - Any page: append `.md` to its URL for this plain-text form --- [Blog](https://dedupe.ly/blog) Team Collaboration ## How to build a deduplication system for RevOps By [Gaby Salinas](https://www.linkedin.com/in/gbyslns) Updated October 22, 2026 # min read TL;DR - A deduplication system keeps working when nobody is running a cleanup project. - One duplicate search per source or scenario makes each search easier to test and trust. - One shared set of rules decides which value wins in every merge. - Alerts come first, and automatic merging on a schedule follows once a search is proven. - Dedupely is a deduplication system with searches, merge rules, scheduled merging, review and history. Many RevOps teams have run a big CRM cleanup. It takes weeks, the duplicate count drops, and months later the same problems are back. The cleanup worked. What was missing was a system around it. New records keep arriving from forms, syncs, enrichment tools and imports, and a one-time project can't keep up with sources that never stop. In this post, you'll see the parts of a deduplication system and how they connect. That covers searches, rules for which value wins, alerts, scheduled merging, review by owner, reporting and a record of every merge. ### What makes deduplication a system A project has an end date. A system has inputs, rules and outputs, and it keeps running while people work on other things. For RevOps, that means each part of deduplication has a clear job. Searches find duplicates, rules decide the outcome, automation handles what's certain, people handle what isn't, and reports show whether it's working. Who owns the system is a separate question. Our post on [CRM deduplication for RevOps teams](https://dedupe.ly/blog/crm-deduplication-revops) covers ownership and how to learn what each team needs. This post is about how the system is built. ### The parts of a deduplication system | Part | Its job | What it needs from you | | --- | --- | --- | | Source map | Lists every tool and process that creates records | An owner for each source | | Duplicate searches | Find duplicates, one source or scenario at a time | Criteria tested on sets you know | | Rules for which value wins | Decide the outcome of every merge the same way | Agreement from the teams that use each field | | Alerts | Tell you when new matches build up | A threshold per search | | Scheduled merging | Merges the duplicates you're certain of | A search that has proven itself | | Review | Sends unclear sets to a person | A rule for who reviews what | | Report and merge log | Show what was found and what changed | Someone who reads them | ### Start with a map of your sources Every duplicate comes from somewhere. In a RevOps stack, that's usually a mix of forms, enrichment tools, call apps, helpdesk syncs, imports and other CRMs. List each source with three facts: what it creates, which field it uses to decide a record already exists, and who owns it. That list becomes the plan for your searches. Sources also change. Add a line to the map every time a new tool connects to the CRM, before its first sync. ### Build one search per source or scenario A single search that tries to catch every duplicate is hard to test. When it pairs the wrong records, you can't tell which part of the criteria caused it. Smaller searches are easier to trust. Give each source or scenario its own search, with criteria that fit the data it produces. - **By source:** an enrichment tool that creates contacts with a name and company domain gets a search on those fields. - **By scenario:** contacts with the same email, companies with the same domain, or leads that match an existing contact's phone. - **By certainty:** a strict search for exact matches, and a looser one for near matches that need review. Filters keep each search focused, for example on records created after a date or on one lead source. What counts as a duplicate is still case by case, so test each search on sets you already know. ### Write the rules for which value wins once Searches can be many, but the outcome of a merge should follow one set of rules. Otherwise, the same customer ends up with a different owner depending on which search found them. Decide which record survives, then go field by field. Owner, lifecycle stage, lead source and email preferences need the most care, since different teams report on them. Keep the rules in one place and change them on purpose. A rule change affects future merges only, so note the date when you change one. ### Alert first, then merge on a schedule New searches shouldn't merge anything on their own. Start each one on alerts only: you get notified when matches reach a number you choose, and you merge by hand. That period tells you how the search behaves on new data. Merge one set, then a page of sets, and reject any match that turns out to be two different records. Once the results stay stable, you can merge new duplicates you're certain of, like exact email matches, automatically on a schedule. Looser searches stay on alerts, with a person deciding. The trade-offs between catching duplicates at entry and on a schedule are covered in [catching CRM duplicates at entry vs. on a schedule](https://dedupe.ly/blog/catch-duplicates-at-entry-vs-schedule). Pro tip When a scheduled search merges something it shouldn't, stop the schedule first, then investigate. Move the search back to alerts until it stops finding false matches. ### Split the review by record owner Automation covers the duplicates you're certain of. The rest needs a person, and the system has to say which person. Two patterns come up often. In the first, one person owns cleanup and sales reps stay out of it, so the CRM changes in one predictable way. In the second, sets are split by owner. - **Same owner on every record:** the merge doesn't change who owns the customer, so these sets are good candidates for bulk or scheduled merging. - **Different owners:** the merge decides who keeps the account, so these sets go to review. When owners differ, the owner of the surviving record or their manager should confirm the result. Write down who decides, so a disputed account doesn't wait for weeks. Example An admin bulk merges the sets where every record has the same owner. Sets with different owners go to review, because nobody knows yet who should own the account. On another team, a rep who finds that someone else owns "their" account tells the admin or their manager, who fixes it. ### Report on the system, not only the cleanup A system needs a signal that it's working. A short report on a regular cadence, weekly or monthly, is enough for most teams. Look at new duplicates per search and per source, sets merged, sets waiting for review and matches rejected. A search that suddenly finds many more matches often points to a source that changed. For the numbers worth tracking, see [duplicate rate and other metrics for a clean CRM](https://dedupe.ly/blog/crm-duplicate-rate-and-data-quality-metrics). ### Keep a record of every merge A record of every merge, with the original values and the values that won, is how you answer questions later. It tells a rep why their account changed and shows a manager which search merged what. If a merge was wrong, it holds the values you need to restore. More on this in [why you need a record of every merge](https://dedupe.ly/blog/crm-merge-history). ### How Dedupely runs a deduplication system for RevOps Dedupely is a deduplication system with a part for each job. You build a Duplicate Search per source, set Merge Rules once and turn on Auto Match for alerts. Once a search is tested, Auto Merge merges its certain matches automatically on a schedule. Unclear sets go to Manual Review, and Merge History records every merge. To split the review by owner, add the owner field to a search. Clone it, try the other match option on the owner field and compare the two results. Our [page for RevOps teams](https://dedupe.ly/solutions/revops) shows the whole setup. [Build your first search per source](https://v2.app.dedupe.ly/signup) ### A system outlasts the cleanup A big cleanup fixes the past. The sources that created those duplicates keep running, so the fix only lasts if something keeps running too. Map the sources, give each one a search, decide outcomes once and let automation handle only what's certain. People review the rest, and a report and a merge log show the whole team that the CRM is being looked after. ### Frequently asked questions #### What is a CRM deduplication system? It's a set of searches, rules and routines that find and merge duplicates on an ongoing basis. Searches find duplicates per source, rules decide which values win, alerts and scheduled merges handle new records, and people review unclear sets. A report and a merge log show whether it's working. #### Should one duplicate search cover the whole CRM? Usually not, because a single search that tries to catch everything is hard to test and its false matches are hard to trace. Separate searches per source or scenario are easier to check, tune and automate one at a time. Exact email matches or records from one enrichment tool are good examples. #### When is it safe to merge duplicates automatically? When a search has proven itself on new data. Start it on alerts only, merge a set and then a page by hand, and reject false matches. Once the results stay stable, merge the matches you're certain of, like exact email matches, automatically on a schedule. #### Who should review uncertain duplicate matches? Often one person who owns cleanup, so the CRM changes in a predictable way, and many teams also split by record owner. Sets with the same owner can be merged in bulk. Sets with different owners go to review, where the owner or their manager confirms the result. #### How do you know a deduplication process is working? Track new duplicates per search and per source, sets merged, sets waiting for review and rejected matches. If new duplicates fall or stay flat while sources keep running, the system works. A sudden jump in one search usually means a source changed and needs a look. Behind the article ### Gaby Salinas Marketing Assistant at Dedupely Gaby Salinas came to CRM data from marketing and advertising, so she looks at duplicates from two sides: the match and merge logic behind them, and what they do to the people using the CRM, like the rep who calls a customer twice, the admin who gets blamed and the cleanup nobody wants to start. As Marketing Assistant at Dedupely, she follows how RevOps teams, end users, consultants and technical teams actually work with their data: the records they stop trusting, the workarounds they build and the moment they finally decide to clean up. What she finds shapes most of what Dedupely publishes. [Connect with Gaby on LinkedIn](https://www.linkedin.com/in/gbyslns) ### Contact us We’d be happy to help you get this set up. #### Write us a message We probably know the answer to your question already help@dedupe.ly Email copied to your clipboard! [Book a Zoom Whether you’re getting started or getting intense. Get in touch! Book a zoom](https://meetings.dedupe.ly/meetings/gaby-salinas/dedupely-zoom-scheduler) ### Discover Related Blog Posts Stay updated with our latest articles and insights. [CRM Organization A RevOps plan for owning CRM deduplication RevOps should own CRM deduplication: the rules, the cadence and the reporting. Start by learning how each team uses records, then merge safely. Gaby Salinas October 19, 2026](https://dedupe.ly/blog/crm-deduplication-revops) [Duplicates Catching CRM duplicates at entry vs. on a schedule Entry rules prevent some duplicates; scheduled searches revisit stored records and missed matches. See how to combine them and review uncertain cases. Gaby Salinas October 19, 2026](https://dedupe.ly/blog/catch-duplicates-at-entry-vs-schedule) [CRM Organization Why you need a record of every merge in your CRM A merge record shows which records went in, which values won, who merged them and when. It answers questions from sales, security and leadership. Gaby Salinas October 19, 2026](https://dedupe.ly/blog/crm-merge-history) ### Get started for free 20 free trial merges and as much free support as you need to get your duplicates under control. [Talk to sales](https://meetings.dedupe.ly/meetings/gaby-salinas/talk-to-sales)[Try for free](https://v2.app.dedupe.ly/signup) [Or sign up with Google](https://v2.app.dedupe.ly/signup/google) Running CRM cleanup for clients? [See the Partner Program](https://dedupe.ly/become-a-partner) Skip to content