TL;DR
- Catching duplicates at entry stops some new records, usually on an exact email or domain match.
- Entry-time matching often misses typos, second email addresses and some imported or synced records.
- Finding and merging on a schedule catches near matches and duplicates already in the CRM.
- Many CRM teams combine native deduplication at entry with scheduled finding and merging.
- Dedupely finds and merges the duplicates that get past entry, with new records ready to match within minutes.
There are two moments to deal with a duplicate. You can stop it as the record is created, or you can find it afterward and merge it with the record it repeats.
Teams often pick one and expect it to cover everything. Entry-time matching sounds safer, since nothing bad gets in.
Scheduled cleanup sounds more thorough because it sees the whole database. Each one catches a different kind of duplicate, and each one misses something.
In this post, you'll see what each approach does, what it lets through, and how to combine them so the gaps don't overlap.
What catching duplicates at entry means
Entry-time matching runs when a record is created or edited. The CRM compares the new record with existing ones and decides what to do before saving it.
Many CRMs include some form of it as native deduplication. How it behaves depends on the CRM and on how the record arrives.
Block, warn or update
Native deduplication usually takes one of three actions. It blocks the new record, warns the user and lets them save anyway, or updates the existing record with the new values.
In one CRM, typing in a contact with an email that already exists is blocked. A form submission with that same email updates the existing contact instead. In another, an admin decides whether a rule shows an alert or blocks the save.
Exact and fuzzy rules depend on the CRM
Some entry-time checks use exact email or domain matches. Others, including configurable Salesforce matching criteria, can compare multiple fields and use fuzzy methods. What gets stopped depends on the active rule, the object and whether the record arrives through a form, import, API or manual entry.
A blocking rule needs careful testing because it can reject a valid record. A warning may let the user review a possible match before saving. Choose the action and criteria for your data; how duplicate matching works in a CRM covers exact and near matching.
As of October 2026, from HubSpot's knowledge base: Deduplication of records, and Salesforce Help: Stop users from creating duplicate records.
What entry-time matching lets through
Entry-time matching does its job on the duplicates it was built for. The rest get in, often for reasons that have nothing to do with how well it's set up.
- Near matches: a typo in the email, a nickname, "Acme Inc." next to "Acme". Exact matching reads these as different records.
- A second email address: the same person signs up with a personal email after buying with a work one. Nothing in the key field matches.
- Records with no key field: a contact typed in with only a name and phone, or an import row without an email. There's nothing to compare.
- Imports and integrations: some entry points follow different rules. In one CRM, companies created through the API aren't matched by domain at all.
- Warnings people click through: a busy rep sees an alert, assumes it's wrong and saves the record anyway.
- Duplicates already in the database: entry-time matching only looks at the record being saved. It never revisits the duplicates you already have.
Blocking has a second cost that's easy to miss. In one CRM, records from data imports and the API get no alert when a rule blocks them, and they aren't saved. If nobody checks what was rejected, that data is gone from the load.
As of October 2026, from HubSpot's knowledge base: Deduplication of records, and Salesforce Help: Things to know about duplicate rules.
What finding and merging on a schedule catches
Scheduled deduplication works after records are saved. A tool or a person looks across the whole database, groups records that belong together and merges them.
A scheduled search can collect uncertain candidates for review before anything changes. Depending on the tool, it can compare typos, sound-alike names, company domains and several fields together. Confirm identity before turning those candidates into merges.
Near matches and groups
Looking across the stored database finds duplicates that the configured entry rules missed. These can include slightly different emails or a person using two addresses. It also finds groups, such as one customer entered by several sources. Some entry rules catch near matches too; the scheduled search provides another review opportunity.
The duplicates you already have
A scheduled run covers old records too. That includes duplicates from before any native deduplication was turned on, from migrations, and from integrations that skipped the entry rules.
Review before anything changes
Nothing is blocked or lost when a record arrives. Uncertain matches can wait for a person to look at them, and the merge result can be checked before it happens.
The trade-off is time. A duplicate exists for a while before it's merged, and in that window it can collect activity or reach a sequence. How long that window should be depends on your sources, which we cover in how often to deduplicate your CRM.
Entry vs. schedule at a glance
| Catching at entry | Finding and merging on a schedule | |
|---|---|---|
| When it runs | As a record is created or edited | After records are saved, across the database |
| What it compares | Exact or fuzzy, depending on the CRM and active rule | Several fields, including near matches |
| What it catches best | Exact repeats from people and forms | Typos, second emails, groups and old duplicates |
| What it misses | Near matches, records with no key field, some imports and integrations | Duplicates that form between runs |
| Who decides | The rule, or a user facing a warning | Rules you've tested, plus review for unclear sets |
| Main risk | Blocked records that aren't saved, or warnings ignored | Loose matching that merges records that aren't duplicates |
Why many teams need both
Each approach covers the other's blind spot. Entry-time matching stops the easy repeats before they spread. A scheduled run finds the near matches and the old duplicates that entry never sees.
The balance between them depends on your data. What counts as a duplicate is case by case, and what one team considers a duplicate, another may not. Write your definition down before you set up either one.
Let entry handle exact repeats
Turn on the native deduplication your CRM offers for the field that identifies each record. Keep its rules narrow, so users trust the warnings instead of clicking through them.
If a rule blocks imports or API records, check what it rejected after each load. The layers that sit around it are covered in how to prevent duplicate contacts in fast-growing sales teams.
Let the schedule handle everything else
Start with the obvious duplicates, like exact matches on email or domain that got in through another door. Then move to near matches on name with company or phone, and send unclear sets to review.
Once your rules are tested, you can merge the duplicates you're certain of, like exact email matches, automatically on a schedule. Keep anything less certain in review.
Watch where duplicates still come from
Each duplicate the schedule finds points back to a source that entry missed. Some sources, like web forms that create new contacts, are easier to fix once than to merge again and again.
How Dedupely catches the duplicates that get past entry
Dedupely works after records are created and picks up new records within 1 to 5 minutes. You build duplicate searches that allow for typos, sound-alike names and shared domains, set rules for which value wins and preview each merge. Once your rules are tested, you can merge new duplicates you're certain of, like exact email matches, automatically on a schedule.
Two moments, one definition of a duplicate
Entry-time matching and scheduled deduplication address the same problem at different moments. Entry rules can use exact or fuzzy criteria, but only cover the objects and entry paths configured for them. Scheduled searches revisit the stored database, with time for people to review uncertain matches.
Used together, they cover each other's gaps. What makes them work is a shared definition of a duplicate. Then the rule at the door and the search behind it look for the same thing.
Frequently asked questions
Is it better to block duplicates at entry or merge them later?
Many teams need both: blocking at entry stops exact repeats, like the same email, before they spread. Merging later catches near matches, second email addresses and old duplicates that entry-time matching never sees. Use entry rules for the exact cases and a scheduled search for everything else, with review for unclear sets.
Why does my CRM still create duplicates with deduplication turned on?
Native behavior depends on the CRM and configured rules. An exact-email check misses a second address or typo, while a multi-field or fuzzy rule may catch it. Some imports and integrations use different rules, users can dismiss warnings, and entry rules do not scan the whole existing database.
Can CRM duplicate rules lose data?
They can, when a rule blocks records nobody reviews. In some CRMs, a blocking rule rejects matching rows from imports and API loads without showing an alert, and those rows aren't saved. Check what each load rejected, and keep blocking rules to matches you're certain of.
How often should duplicates be merged after entry?
It depends on how quickly your sources add records. With steady forms and integrations, teams often merge certain matches automatically on a schedule and review the rest regularly. Teams that mostly import lists can check after each import, aiming to merge before duplicates reach reports and sequences.
What is entry-time duplicate matching?
It is matching when a record is created or edited. Depending on the CRM, rule and entry path, the comparison can be exact or fuzzy. The system may block, warn or update an existing record. Test each path rather than assuming one rule covers every new record.
Or sign up with Google
