CRM data hygiene with n8n: stop duplicates at entry, merge safely with review tiers, standardise fields and flag stale records in HubSpot, Zoho or Pipedrive.
Most CRMs do not get messy because people are careless. They get messy because data arrives from five directions, nobody agreed on a format, and the system accepts whatever it is given.
The usual response is a big cleanup project: export everything, spend a weekend in a spreadsheet, merge duplicates, re-import. It works, and a few months later the CRM looks the way it did before. Cleanup treats the symptom. The cause is that duplicates and inconsistencies are created at the point of entry, every day.
This post covers the approach I would use in n8n: stop most mess at the door, run a scheduled job to catch what gets through, and keep a human in the loop for any decision that cannot be undone. It works for HubSpot, Zoho CRM and Pipedrive.
Why CRM data decays
Fact: Duplicates in a CRM usually come from a handful of causes:
The same person enquires through two channels, such as a web form and WhatsApp.
One person uses a work email on one form and a personal email on another.
Phone numbers are stored in different formats: "+91 98765 43210", "98765 43210", "919876543210".
A rep creates a record by hand without searching first.
A list import is loaded without checking what already exists.
Company names are typed in several ways: "Acme Pvt Ltd", "Acme Private Limited", "ACME".
My read: Almost all of these can be prevented or caught automatically. The ones that cannot, like two genuinely different people with the same name, are exactly the cases that need a human decision.
The principle: fix it at the door
The cheapest duplicate to remove is the one that was never created. Every lead source should write to the CRM through one routine that normalises the data and checks for an existing record first.
Use a stable match key and upsert
Fact: HubSpot supports upserting contacts using email as a unique identifier. Zoho CRM's upsert endpoint accepts duplicate-check fields. Pipedrive does not enforce uniqueness the same way, so the workflow should search for an existing person before creating one.
Use email as the primary key, with normalised phone as the fallback. When either matches, update the existing record. When neither does, create a new one.
Normalise before you match
Matching only works if the keys are comparable. Normalise these before comparing:
Email: trim spaces and lowercase it.
Phone: reduce it to digits and convert to E.164 format with a country code.
Company domain: take the domain from the email address, but ignore free-mail domains. Two people at gmail.com do not work for the same company.
A Code node (run once for all items) can add these as match keys:
This is deliberately simple. It assumes ten-digit numbers belong to your default country, which is wrong for international data. If your contacts span many countries, use a proper phone-parsing library or service, and test it against a sample of your real numbers.
Be careful with email "cleverness"
Some tools strip dots or plus-tags from Gmail addresses to treat "a.b@gmail.com" and "ab+shop@gmail.com" as the same person. That is true for Gmail but not for every provider, and a wrong guess merges two real people. Lowercase and trim, and stop there unless you have a reason.
The scheduled job: catch what got through
Even with a clean entry routine, some duplicates will exist already or arrive through manual edits and imports. A nightly n8n workflow handles those.
1. Pull recently changed records
Fetch only records created or modified since the last run, using the CRM's modified-since filter, instead of reading the whole database every night. This keeps API usage low, which matters because each CRM enforces plan-based API limits.
2. Compute match keys and look for candidates
Calculate the normalised keys, store them in a PostgreSQL table alongside the CRM record ID, and query that table for other records sharing a key. A small index table makes matching fast and gives you an audit trail.
3. Sort candidates into three tiers
Tier
Example
Action
Certain
Same normalised email
Merge automatically
Likely
Same phone and similar name, different email
Add to a review queue
Possible
Similar name and same company domain
Add to a review queue, lower priority
My read: Automatic merging should be limited to near-certain matches. A wrong merge is much harder to undo than a leftover duplicate. Fact: HubSpot's merge of contacts cannot be undone once complete, so treat any automated merge as permanent.
4. Decide which values survive
When two records merge, you need a rule for each field. A sensible default:
Keep the oldest created date, so history is preserved.
Keep the current owner unless the record has no owner.
For other fields, keep the most recently updated non-empty value.
Never overwrite a value a rep typed by hand with one that came from an import or enrichment.
Combine activity history, notes and associations onto the surviving record.
Write these rules down. If you cannot explain why a field ended up with a particular value, you cannot defend the merge.
5. Merge through the CRM's own API
Fact: HubSpot, Zoho CRM and Pipedrive each provide merge functionality through their APIs, and using it keeps associations and activity history intact. Avoid a delete-and-recreate approach, which breaks links and timelines.
6. Log everything
For every merge, write a row to an audit table: both record IDs, the match tier, the rule that fired and the before and after values of key fields. When someone asks "where did this contact go", you can answer in seconds.
7. Dry run first
Before the first live run, execute the whole workflow in a mode that writes nothing and outputs a CSV of what it would merge. Review a sample by hand. This is the single most useful safety step, and it is the one most often skipped.
Standardising fields
Once duplicates are under control, consistency is the next problem. Small, high-value standardisation covers:
Phone numbers in E.164.
Country and state from a fixed list, so reports and routing rules work.
Lifecycle and lead status values mapped to one agreed set.
Job titles grouped into a few seniority levels, if you segment by seniority.
Name casing, with care. Automatic capitalisation breaks names like "McDonald", "D'Souza" and "van der Berg", so only fix names that are entirely uppercase or lowercase, and leave the rest alone.
My read: Standardise the fields you actually filter, route or report on, and leave the rest. Over-normalising creates work and risks damaging correct data.
Enrichment, used sparingly
Enrichment fills missing company data such as industry, size or location from an external source. It can help routing and segmentation, but treat it with caution:
Fill empty fields only. Never overwrite what a person or a rep has entered.
Check the data source's reliability for your market before trusting it.
Consider privacy and consent. Collecting more personal data about someone than you need, or without a lawful basis, can create legal problems depending on where your contacts live.
Watch the cost per lookup, which adds up on large lists.
Keeping data fresh
A clean record that is out of date is still a problem. Useful scheduled checks:
Bounced emails: mark the address as invalid so it stops hurting your sending reputation.
Unsubscribes and do-not-contact flags: make sure they are respected everywhere and never reversed by an import.
Stale deals: flag open deals with no activity past a threshold you choose, and assign a task to the owner.
Orphans: find contacts with no company and deals with no contact.
Where it goes wrong
Auto-merging on weak matches. Keep automatic merges to near-certain cases.
Matching on free-mail domains. Exclude gmail.com and similar from company matching.
Overwriting rep-entered data. Decide field ownership up front.
Re-subscribing opted-out contacts. Import and merge routines must preserve consent and opt-out status.
No audit trail. Without a log, mistakes cannot be traced or fixed.
Skipping the dry run. Always preview before any bulk change.
Running against the whole database every night. Use modified-since filters and batch calls to stay inside API limits.
What it costs to run
The running cost is small. A self-hosted n8n server with a small PostgreSQL database is roughly $6 to $20 a month (about 550 to 1,800 INR), and n8n Cloud starter plans are roughly $25 to $70 (about 2,200 to 6,300 INR), based on execution volume. A nightly job plus the entry routine uses few executions. These are estimates, rounded at about 90 INR to the dollar, so confirm current prices. The real cost is the design and testing time, especially agreeing the merge rules.
Frequently asked questions
Nightly works for most teams, since it catches the day's duplicates before anyone builds on them. For low-volume CRMs, weekly is enough. The entry routine runs continuously, because it acts on every new lead.
Duplicates are an entry problem more than a cleanup problem. Normalise and upsert at the door, run a nightly job for what slips through, merge automatically only when the match is certain, send the rest to a person, and log every change. Clean data then stays clean.
Ready to Build?
Let's create something together
If you want this built and owned by you, see our CRM Migration and Data Cleanup service, or our CRM Automation with n8n service for the ongoing routines. A 30-minute call is enough for me to tell you how messy your data really is.
