CRM data cleansing: a routine that clears the duplicates out of your database, and the rules that stop them coming back.

What is CRM data cleansing?

CRM data cleansing is the work of finding and correcting records in your CRM that are wrong, incomplete, duplicated or long dead, so the system your team sells from matches the companies and people outside it.

It covers four jobs that get confused with each other: removing junk, merging duplicates, standardizing the values inside fields, and filling real gaps. Each job has its own rules, its own risk of damage, and its own owner.

Cleansing is never a project that finishes. A CRM takes in records every day from forms, imports, integrations and reps typing fast between calls, so the mess returns unless the intake rules change as well.

This guide gives you a cleanup routine you can run this quarter, and the prevention rules that keep the next one small. It treats your CRM as the system of record for customer data, not as a filing cabinet.

Data cleansing, data cleaning and data scrubbing

The three terms describe the same job, and no standards body owns the difference. Treat data cleansing and data cleaning as interchangeable, and treat data scrubbing as the same work with the emphasis on removing bad records rather than correcting them.

What matters is scope, not vocabulary. Ask whether a given piece of work is about duplicates, about values inside fields, about missing information, or about records that should no longer be in the customer database at all.

The dimensions of CRM data quality

Clean is not one property. When a data quality tool reports on a customer database it is measuring several separate things, and your cleansing plan should name which ones you are fixing this quarter.

These dimensions also tell you what a cleaning tool is really offering. A tool that finds duplicates is selling uniqueness, and a tool that fills firmographics is selling completeness, not accuracy.

What dirty CRM data costs a team

Nobody files a ticket for bad data. The cost shows up somewhere else, usually in a meeting where two people quote different numbers from the same system.

• Wasted outreach: reps call disconnected numbers and email addresses that bounce, then blame the channel instead of the record.
• Double touches: two reps work the same company under two account records, and the buyer notices before either rep does.
• Broken routing: territory, owner and lifecycle rules read fields that are empty or spelled six ways, so leads land nowhere.
• Reporting nobody trusts: pipeline and account counts are inflated by duplicates, so forecasts get argued instead of used.
• Segments that miss: campaigns built on industry or employee count skip the records where those fields were never filled.
• Slow onboarding: a new rep cannot tell which of three records for one buyer holds the real history.
• Compliance exposure: an opt-out recorded on one duplicate does not protect you when the other duplicate gets mailed.

The seven kinds of dirty data in a CRM

Treating all of it as one problem is why cleanups stall. Sort the mess into types first, because each type has a different fix and a different level of risk.

Write this table for your own CRM with real counts next to each row. That single page turns "our data is a mess" into a work order that someone can actually finish.

Audit before you change a single record

A cleanup that starts with deleting is a cleanup that ends with an apology. Start by measuring, on a copy, so you know the size of each pile and can prove the change later.

• Export everything first. A full export of the objects you will touch is your only realistic undo for merges.
• Count by type. How many suspected duplicates, empty required fields, bouncing addresses, records with no owner, records with no activity in a year.
• Profile the worst fields. List the distinct values in country, industry, job title and lifecycle stage, sorted by frequency. The tail is your standardization work.
• Find the sources. Group new records by how they arrived: form, import, integration, manual entry. One source usually creates most of the mess.
• Check the dates. Records created in a single week in bulk are almost always an import that nobody deduped.
• Agree on "clean". Write the definition down before you start, or every reviewer will use a different one.

The audit output is a short document: counts, the three worst intake sources, and the fields you will constrain. Everything after this is execution against that list.

Customer data deduplication: match first, merge second

Customer data deduplication is two separate decisions that people run together and regret. Matching decides which records describe the same person or company. Merging decides what the one surviving record keeps.

Keep them apart in your process, because matching is reversible and merging usually is not. Review a match list, approve it, and only then merge.

Cross-object duplicates need the same treatment. Deduplicating contacts while leads for the same people sit untouched leaves the problem in place, just one object over.

Matching rules, and what exact matching misses

Out of the box, most CRM deduplication starts from an exact value in one field. That catches the easy cases and leaves the rest.

What the major CRMs match on by default

HubSpot documents that it automatically deduplicates contacts by looking for a matching value in the Email property, and companies by the primary value in the Company domain name property.

HubSpot also documents that Record ID can be used as the unique identifier on import, that a mapped Record ID supersedes other mapped identifiers, and that companies created through the API are not deduplicated by the domain property.

Microsoft documents that Dataverse ships duplicate detection rules for accounts and contacts only, turned on by default, and that you create your own rules for other record types.

Exact, fuzzy and the thresholds behind them

Salesforce documents two matching methods. The exact method looks for strings that exactly match a pattern and works on almost any field, including custom fields. The fuzzy methods look for strings that approximately match.

Salesforce publishes the score threshold each fuzzy method uses: 85 for first name, 90 for last name, 70 for company name, 80 for phone, 85 for city, 80 for street, 80 for ZIP and 50 for title.

Salesforce also documents that the company name method removes words such as "Inc" and "Corp" before comparing, and normalizes names, giving "IBM" normalized to "International Business Machines" as its example.

Salesforce notes a limit worth knowing before you trust a rule: match keys narrow the comparison to the 100 most likely duplicates first, and the matching equation is applied only to those.

Rule options that change what you catch

A practical B2B rule set compares more than one field at once: work email, or company domain plus last name, or phone plus company. One field alone either misses too much or merges strangers who share a common name.

Merge order: choosing the record that survives

The survivor is usually called the master, primary or principal record. Choosing it by hand, record by record, is how a cleanup becomes a month of work and still ends up inconsistent.

Write a survivor rule instead and apply it the same way every time. A workable order for B2B records, in priority:

1. The record with an open deal or an active owner

   Pipeline and ownership carry the most operational weight. Losing the record a rep is working on is the failure people notice first.

2. The record synced to another system

   If one record carries an external ID from your marketing platform, billing or support tool, keeping it avoids breaking the link between systems.

3. The record with the most activity history

   Emails, calls and meetings are the record's memory. The record the buyer actually appears in should generally win.

4. The record with the most filled fields

   Use completeness only once the rules above tie, and count fields that matter, not every custom field ever created.

5. The most recently updated record

   Recency is the last tiebreaker, not the first rule. A record touched by an import yesterday is not more true than one a rep updated last month.

Then set field level rules on top: keep the non-empty value, prefer the verified email over the guessed one, prefer the specific industry over the default one. The survivor rule picks the frame; field rules decide the contents.

What a merge actually does to the other record

Merging is where the risk lives, because the platforms differ and most of them do not offer an undo. Read your own CRM documentation before the first bulk run.

Two rules follow from that table. Run the first merges in small approved batches, and keep the export from the audit until you have confirmed a sample by hand.

Standardizing fields so one value means one thing

Standardization is the quiet half of cleansing. Duplicates get the attention, but inconsistent values break routing, segmentation and reporting just as effectively and are far cheaper to fix.

Domains are the sturdiest key in B2B. Company names change spelling constantly, while a domain is a value two systems can agree on, which is why so much B2B data work anchors on it.

Keep raw values somewhere. Overwriting the title a buyer wrote themselves, with your tidy version, throws away a signal your team may want later.

Validation at entry, and the gaps in it

Every hour spent on intake rules is an hour you do not spend cleaning later. Validation runs in three places: the form, the CRM field, and the import.

• Required and constrained fields: picklists instead of free text on anything used for routing, segmentation or reporting.
• Format validation: reject phone numbers with too few digits and addresses that are not syntactically valid before the record saves.
• Verification at the form: check email deliverability at submission, so email bounces never reach your sender reputation.
• Blocked free domains: decide whether a free email domain is allowed on a B2B form, and enforce that choice consistently.
• Duplicate prompts: show the rep the possible match at the moment of creation, with a merge option, not a warning they can skip blindly.
• Import staging: no file goes straight into production. It gets deduped, standardized and reviewed outside the CRM first.

Now the gaps, which are the part people learn the hard way. Salesforce documents that duplicate rules do not run when records are created with Quick Create, restored with Undelete, or manually merged.

Salesforce also documents that duplicate rule settings are overridden when records are added using data import tools, or added and edited through Salesforce APIs: no alert is shown, and users cannot save records.

Salesforce further documents that a rule set to run on edit only runs when the edited fields are included in the associated matching rule, and that simultaneously saved records are compared only with records already in Salesforce, not with each other.

Read that as one instruction: your integrations and your bulk imports are the two doors validation does not guard. Guard them with a staging step you control.

Bulk cleanup versus continuous hygiene

These are not competing approaches. You need one of each, and the reason cleanups repeat forever is that teams run the first and skip the second.

Sequence matters: audit, then one scoped bulk pass, then the prevention rules, then a schedule. Skipping straight to the schedule is how a cleanup becomes an annual ritual.

Who owns CRM data quality

Data quality without a named owner is everyone's complaint and nobody's task. The ownership question has three parts, and they belong to different people.

In most teams this sits under revenue operations, and the split between strategy and daily administration is the same one covered in RevOps vs sales ops.

Make the rep's part small and specific. "Fix your data" gets ignored. "Twelve of your accounts are missing an employee count, due Friday" gets done.

A CRM data cleansing schedule that survives a busy quarter

A schedule only holds if each task is short enough to fit in a normal week. Build it from small recurring jobs, not from an annual crisis.

The email side of this belongs on its own cadence. Validation, bounce handling and suppression are covered in email hygiene, and a catch-all email domain needs a rule of its own.

What to do before a CRM migration

A migration multiplies whatever you send into it. Dirty records arrive dirty, duplicates arrive doubled, and the new system inherits the old problem with none of the old context.

• Clean in the old system, not the new one. You still have the history, the owners and the people who remember why a field exists.
• Dedupe before export, then again after import. The export is a snapshot; new duplicates appear in the gap between the two.
• Map identifiers deliberately. Decide which field is the key in the new system and carry the old record IDs into a field you keep.
• Carry suppression and consent forward. Opt-outs, do not call flags and consent dates are the one thing you cannot rebuild later.
• Decide what does not travel. Junk records, dead custom fields and abandoned stages should not be migrated out of politeness.
• Import in staged batches. One object at a time, smallest first, with a verification pass between batches.
• Freeze changes during cutover. Edits made in the old system mid-migration are the duplicates you will find in month two.

Test the whole run on a subset in a sandbox. The first full import is the wrong place to learn how your new platform handles blank values.

How to run a CRM data cleansing project

1. Define clean in writing

   List the required fields, the allowed values and the rule that makes two records duplicates. One page, agreed with sales, marketing and the CRM admin before anything changes.

2. Export and profile

   Take a full export, then count duplicates, empty required fields, invalid addresses and records with no activity in a year. These counts are your before picture.

3. Remove the junk

   Delete test records, spam form fills and obvious garbage first. It is the lowest risk work and it shrinks everything that follows.

4. Match, review, then merge

   Run the matching rules, review the candidate list with a person, approve it, and merge in small batches against your survivor rule.

5. Standardize the fields that drive decisions

   Fix country, industry, title, phone and lifecycle stage, then constrain those fields so the old values cannot come back.

6. Validate and fill the real gaps

   Verify emails and phones, then fill missing firmographics from a source you trust. Do not overwrite verified values with guesses.

7. Close the doors that let it in

   Change the form, the import process and the integration mapping that produced most of the mess. This step is the one that makes the cleanup last.

8. Publish the numbers and set the schedule

   Report the before and after counts, then put the recurring tasks on the calendar with named owners. Review the report monthly.

What to archive instead of delete

Deleting feels like progress and is sometimes the wrong move. A record with no recent activity is not automatically worthless, and some of it you are obliged to keep accurate rather than remove.

The UK Information Commissioner's Office states the accuracy principle as personal data being accurate and, where necessary, kept up to date, with every reasonable step taken to erase or rectify inaccurate data without delay.

The ICO also notes that what counts as a reasonable step depends on the circumstances, and that more effort is expected when the data will have a significant effect on someone.

The ICO guidance adds that records may legitimately show what happened, including a mistake that was later corrected, as long as the record itself stays factually accurate and the correction is noted.

• Archive: past customers, closed lost deals, contacts who changed jobs, and anything tied to a contract or an invoice.
• Suppress, do not delete: opt-outs and do not contact flags. Deleting the record deletes the proof that they asked.
• Delete: test records, spam, and personal data you have no purpose for and no obligation to keep.
• Correct and note: data a person tells you is wrong, with the correction and its date recorded.

How to measure whether the CRM got cleaner

Pick a handful of counts, publish them monthly, and change one rule at a time so you can tell what moved the number.

New duplicates per week is the single most useful number on that list. It separates a cleanup that fixed the backlog from one that also fixed the cause.

Tools, as categories

This page does not rank vendors or quote prices. These are the categories a cleansing program uses, and several of them may already be included in your CRM.

• Native duplicate management: matching rules, duplicate rules and merge dialogs built into the CRM. Start here before buying anything.
• Dedicated deduplication tools: fuzzy matching, bulk merge with survivor rules, and scheduled jobs across objects.
• Validation services: email and phone verification at the form and in batch.
• Enrichment: fills firmographics and contact fields, covered in lead enrichment and through a data enrichment API.
• Integration and sync layers: where field mapping decides whether two systems fight over the same value.
• Reporting: the dashboard that shows your data quality metrics, wherever your sales tech stack already reports.

Any tool that merges records needs the same governance as a person doing it by hand: an approved rule, a review step, and an export taken before the run.

Common CRM data cleansing mistakes

• Merging before anyone reviewed the match list, on a platform with no unmerge.
• Cleaning the database and changing nothing about how records arrive.
• Trusting exact match on one field, then declaring the CRM duplicate free.
• Deleting opt-outs along with the contact record, and losing the proof.
• Enrichment set to overwrite, quietly replacing verified values with worse ones.
• Standardizing job titles in place, destroying what the buyer actually wrote.
• A cleanup owned by a committee, so no single person can approve a merge.
• Running the whole thing without an export, and finding out too late.
• Migrating everything because deciding what to leave behind felt political.

Telling the team before you touch their records

Reps notice when accounts disappear from their view, and a merge looks exactly like a deletion from the outside. Tell them what is happening, what to check, and how to object before the batch runs.

The message below was written for this page. It assumes a scoped merge batch with a review window, which is the only kind you should be running.

Subject: {{count}} duplicate records in {{object}} get merged on {{date}}

Hi team,

We found {{count}} sets of duplicate {{object}} records in the CRM. On {{date}} each set becomes one record, keeping the one with the open deal or the active owner. Activities and notes move across.

The list is here: {{link}}

If a pair on that list is not actually the same company, reply by {{deadline}} with the record names and we will leave them alone. Nothing gets deleted, and the export is kept.

{{senderName}}

Frequently asked questions