Duplicates Are Not A Cleanup Job | Zoho CRM Deduplication And Unique Fields

Somebody in your company has cleaned up duplicate records. Possibly more than once. Possibly it's on a list for this quarter.

That's the mistake, and it's a structural one rather than a lazy one. Cleaning duplicates is maintenance. A duplicate is not a mess — it's a rule you never wrote, and until you write it you will be cleaning them for as long as you own the system.

Everything on screen is a mock demo of Zoho CRM with sample data.

Start with where Zoho puts this, because the location is an argument in itself. Deduplication isn't in Setup at all. It isn't a configuration screen. It's an action, inside a module, sitting in the same menu as mass update and mass delete.

In other words, the product files it as housekeeping. You run it, it finds matches, you merge them, and nothing about your system has changed. Tomorrow the form on your website can create the same duplicate again.

Here's why this stopped being cosmetic the moment you turned on an agent. From our own readiness work: agents reason across duplicate accounts as if they were separate businesses.

Think about what that does. Two records for one customer. The agent finds one of them, answers your question completely and confidently from that half, and never mentions the other. What you get is a third of the answer delivered with the confidence of a whole one.

A human looking at the same screen might notice the name twice. An agent has no reason to.

There's a reporting consequence too, and it's worth naming plainly. Every count you produce is inflated by exactly the duplicates you haven't found. Account totals. Customer numbers. Coverage figures. The denominator in any conversion rate you put in front of a board. And you cannot correct for it, because correcting for it would require knowing how many duplicates you have — which is the thing you don't know. That is a different problem from a number being wrong. It's a number whose error bar is unknowable until you fix the cause.

And duplicates rarely look like duplicates. Here are two records. Same company, one written out in full and one abbreviated. Different email domains, because one came from a web form and one from a conference list. Different owners. One has the deal history; the other has the phone number that actually works.

No exact-match check catches that pair. A person can see it in two seconds and cannot see it across forty thousand records.

Now the other side of the same page — validation rules. A validation rule refuses a record that doesn't meet a condition, at the moment somebody tries to save it. Not a warning. A refusal.

This is the difference between the two approaches. Merging duplicates is work you do after the fact, repeatedly, forever. A validation rule is a decision you make once, and the system then holds it for you.

But be precise about where it holds, because this is the part that would otherwise sink the argument. A validation rule fires on typed entry. It is bypassed by import. It's bypassed by the API. It's bypassed by a workflow field update, by an approval, and by a Blueprint transition. So a validation rule is a good, narrow instrument — it stops a person typing the wrong thing — and it is not a wall around your database.

Which matters, because the doors duplicates actually come through are mostly the ones it doesn't cover. Hold that thought — there's a second control coming that does.

So here's the shift, and it's one sentence. Stop asking who will clean the duplicates. Ask what makes two records the same record.

Answer that in your own business — is it the email domain, the company name and city, a customer number from another system — and you have a rule.

Then set that field to not allow duplicate values, because that is the control that actually covers the doors: manual entry, import, the API, web forms, mobile. Add a validation rule if you also want to catch a person typing something malformed — but the unique field is the one doing the structural work.

Then merge what's already there, once, on the records created before the rule existed. And go into that one clear-eyed: a merge is permanent. The losing records are deleted, not recycled. Notes, attachments and activities move to the master, and the master is chosen for you — the record with the most recent activity. Three records at a time, three match fields.

That ordering is the difference between a cleanup and a fix. Rule first, then merge. The other way round and you're just buying yourself a quieter quarter.

Before the fix, be specific about where duplicates come from, because a rule has to cover every door. There are four, usually. A rep typing quickly, on a phone, who doesn't search first. A spreadsheet import where somebody mapped a column optimistically. An integration creating records from another system that has its own idea of identity. And a web form, which is the worst of the four, because the person filling it in genuinely does not know they're already in your database.

A merge pass closes none of those doors. It cleans up behind all four and leaves them open.

Here's the setting almost nobody uses, and it takes two clicks to reach. Open a field's menu inside the layout editor. There are exactly two options on it. Mark as required — and the one that matters here — do not allow duplicate values.

That is the whole control. Switch it on for a field and Zoho stops a second record being saved with the same value in it. Not a report you read at the end of the quarter. A refusal, at the moment somebody tries.

The reason it goes unused isn't that it's hidden. It's that using it requires deciding which field carries identity in your business, and that decision has consequences somebody has to own.

Email is the obvious candidate and often the wrong one — two people at one company share a switchboard address, and one person has three addresses. A customer number from an upstream system is usually better, if you have one.

Four things to know before you pick. You get two unique fields per module, so this is a real choice and not a checklist. It's paid editions only. It is not case sensitive, which is usually what you want. And on Leads and Contacts, Email is not unique by default — somebody has to turn that on.

And unlike the validation rule we just looked at, this one does hold at the doors: manual entry, import, the API, web forms, mobile. That's the difference between the two controls, and it's the whole reason to reach for this one first.

Deciding what makes two records the same record is a business decision, not a technical one, and it's the part that gets skipped because it needs somebody to actually choose.

We'll run that decision with you and build what enforces it. Discovery is no-risk — you pay for it only if you proceed.

CodeStringers. Zoho authorized consulting partner, Santa Cruz.