A duplicate rule has two jobs that should stay separate: find a plausible match, then choose a safe action. Salesforce documents this distinction directly: a matching rule compares records, while a duplicate rule or job decides how those matches are handled. Keeping those steps separate makes false positives inspectable instead of turning one similarity score into an irreversible data change.
Lead deduplication match methods
| Match method | What it establishes | False-positive risk | Safe default |
|---|---|---|---|
| Exact provider event or submission ID | The same upstream event was received again in the same Intake scope | Low when the provider documents uniqueness and scope | Return the existing Lead instead of creating another |
| Exact normalized email | Two Leads supplied the same canonical email value | Shared inboxes, recycled addresses, and entry errors | Combine with time, Business, phone, and inquiry context |
| Exact normalized phone | Two Leads supplied the same canonical phone value | Shared household lines, reassignment, or a mistyped number | Treat as strong evidence, not automatic person identity |
| Email and phone within a defined window | Two inquiries share two contact paths in a relevant period | A real person may be asking about a new need | Hold or suppress by documented Business policy and preserve the inquiry |
| Fuzzy name, company, or address | The records are similar enough to inspect | Different people can look similar after normalization | Create a review candidate; never merge from fuzzy evidence alone |
| Browser, session, or payload fingerprint | The submissions share technical context | Shared devices, retries, privacy changes, or unstable fingerprints | Use as corroboration, not durable identity |
Exact and fuzzy do not mean safe and unsafe. They describe how the candidate was found. Microsoft Dynamics 365, for example, documents exact email and phone rules alongside similar-name rules that use company or email-domain context. Its interface presents possible duplicates for comparison before merge, which is a useful design clue: similarity should create evidence and a review path, not silently erase a record.
1. Stop technical retries before person matching
The safest duplicate is a replay with the same provider event or submission ID. If an upstream system retries because it did not receive a response, the Intake can use that stable identifier to return the already-created Lead. This is an idempotency decision about one event, not a claim that two people are the same.
Lucidity's Intake documentation describes provider identifiers as the way repeated provider messages avoid an accidental second Lead. Website form capture follows the same observable pattern: a duplicate submission returns the existing Lead ID with a duplicate marker. Keep this replay guard ahead of contact matching so transport retries do not enter a fuzzy identity workflow.
2. Normalize values without discarding the original
Compare canonical values, but preserve the submitted values for audit and correction. Phone comparison should use one documented regional parsing policy and a canonical representation when parsing succeeds. Email comparison should apply a documented policy that handles whitespace and domain casing without inventing provider-specific aliases. Names and addresses need Unicode-safe comparison that does not erase accents, apostrophes, hyphens, mononyms, or meaningful unit details.
Normalization makes equivalent formatting comparable. It does not prove that a phone, email, name, or address belongs to the same person. Store the original value, normalized value, parser or rule version, and any failure reason separately.
Vendor rules illustrate why implementations differ. Salesforce's standard contact and Lead matching documentation combines exact and approximate algorithms with field-specific handling and notes that part of its phone behavior works best with North American data. Copying a vendor threshold without its scope and assumptions is not a portable deduplication policy.
3. Scope every rule to the correct ownership boundary
Run duplicate detection inside the Business that owns the Lead. The same email or phone can legitimately appear in different client businesses, and one agency's Workspace is not permission to merge those records across clients. Cross-Business discovery also creates an avoidable privacy and access-control risk.
Within a Business, scope stable provider IDs to the provider and Intake that issued
them. A bare value such as 12345 is not globally unique unless the
provider contract says so. Use a composite idempotency key such as provider, Intake,
and provider event ID, then enforce uniqueness transactionally.
4. Choose time windows from the inquiry cycle
There is no universal duplicate window. A short callback form, a seasonal quote, and a long-consideration service have different repeat behavior. Define the window per Business from the period in which a second submission is likely to be an accidental repeat, then review real outcomes before making it stricter.
- Name the event being suppressed. A provider retry, double click, repeated inquiry, and existing person are four different situations.
- Use the strongest scoped key first. Prefer a stable event ID over a contact field and a contact field over fuzzy name similarity.
- Set the window from evidence. Record the rule version and compare review releases, repeat interest, and sales feedback after changes.
- Keep history outside the window. An older relationship can inform review without automatically suppressing a new inquiry.
5. Separate a duplicate person from a repeat inquiry
A Lead is an inquiry, not a permanent person profile. One person can ask about two services, return after a prior attempt failed, use a different contact path, or submit new information that changes contactability. A system that always merges by email may keep the person record tidy while losing the new sales event.
HubSpot's current documentation shows why the action matters: when a form submission uses an email that already exists, new contact information is added to the existing contact. That is a documented CRM contact behavior, not a universal rule for preserving first-party Lead inquiries. Decide separately whether to update a person, link two Leads, hold the new Lead, or suppress a confirmed event replay.
6. Map match evidence to safe outcomes
| Evidence state | Lead action | Delivery action | Evidence to preserve |
|---|---|---|---|
| Exact event replay | Return the existing Lead | Do not create a duplicate Delivery from the retry | Scoped idempotency key and replay timestamp |
| Strong recent contact match | Record a duplicate Validation Check | Hold from automatic Delivery unless policy explicitly allows it | Matched Lead, fields, window, rule, and reason |
| Fuzzy or conflicting match | Keep the new Lead and mark it for review | Wait for an operator decision | Candidate set, similarity evidence, and conflicts |
| Repeat interest with new evidence | Preserve the inquiry and link relevant history | Route according to the current Validation Outcome | New interest, changed contact evidence, and prior relationship |
| Matcher or provider error | Keep error separate from duplicate evidence | Retry or hold under documented fallback policy | Error class, timing, retry count, and fallback used |
In Lucidity, duplicates can be one Validation Check inside a wider Validation Run. The
public
Validation Outcome contract
keeps qualified, review, blocked, and
error distinct. Duplicate-related ambiguity belongs in review; an error
is not evidence that two Leads match; and a Business can reserve blocked outcomes for
explicit strict suppression or independently strong bad-contact evidence.
7. Make every match explainable
| Field | Purpose | Safety note |
|---|---|---|
| Candidate Lead ID | Points to the earlier record considered a match | Resolve it only inside authorized Business scope |
| Match kind | Names provider ID, email, phone, composite, or fuzzy evidence | Do not expose raw sensitive values in logs |
| Rule and version | Explains which policy made the decision | Keep historical versions interpretable after policy changes |
| Window and timestamps | Shows why the earlier Lead was eligible for comparison | Use Business-local reporting context without changing stored instants |
| Outcome and reason codes | Connects evidence to review, block, qualify, or error | Prefer small machine-readable reasons over free-form personal data |
| Operator decision | Records release, continued hold, or strict suppression | Keep actor, time, and rationale auditable |
8. Test false positives and repeat inquiries
| Synthetic case | Expected result | Failure caught |
|---|---|---|
| Same provider ID, same Intake, second request | Existing Lead ID returned; no second Lead or Delivery | Retry creates duplicate work |
| Same phone and email inside the configured window | Duplicate evidence recorded with the earlier Lead | Exact match is invisible or unexplained |
| Shared phone, different names and emails | Review candidate; no silent merge | Household or shared-line false positive |
| Same email, new interest outside the window | New inquiry preserved with relevant history | Repeat demand disappears |
| Similar names, no shared contact path | No automatic suppression | Fuzzy name match becomes identity proof |
| Match service timeout | Error or documented fallback, never blocked as duplicate | Infrastructure failure becomes bad-contact evidence |
| Same contact values in different Businesses | No cross-Business candidate or data disclosure | Client boundaries leak |
Add these cases as regression tests whenever normalization, provider mappings, duplicate windows, Validation Outcomes, or Delivery retry logic changes. The Lead qualification checklist covers the surrounding contactability checks, while the form spam protection guide separates capture controls from duplicate evidence.
9. Measure deduplication without calling every match a win
Report exact event replays, contact-match candidates, Review Leads, operator releases, strict suppressions, and repeat inquiries separately. Put the denominator beside every rate: duplicate candidates divided by accepted Leads is different from replayed events divided by Intake requests. Track changes by Business, Source, Intake, rule version, and window.
Use Lucidity Lead, Validation, and Delivery records as the first-party facts for this workflow. GA4 can add traffic and campaign context, but it does not prove whether two Lead records represent the same person or whether a Delivery occurred. The Lead quality improvement guide shows how to connect these measures to review and routing outcomes without reducing quality to raw submission volume.
Primary sources checked August 22, 2026
- Salesforce Help: Duplicate Detection and Handling Process
- Salesforce Help: Standard Contact Matching Rule and Standard Lead Matching Rule
- Microsoft Learn: Manage duplicate leads
- HubSpot Knowledge Base: Deduplicate records in HubSpot
- Lucidity documentation: Intakes and capture
- Lucidity documentation: Tracking Pixel and website form capture
- Lucidity documentation: Lead Validation
Frequently asked question
How should duplicate Leads be detected without merging different people or losing a new inquiry?
Use exact provider identifiers only for transport retries, normalize contact fields before comparison, keep fuzzy matches as candidates rather than verdicts, and scope every rule to the correct Business and time window. Preserve the matched Lead, rule, and reason as auditable evidence, then hold ambiguous matches for review. A repeat person can still have a new inquiry, so do not silently merge Lead records or discard new interest.
Keep duplicate evidence visible before Delivery
Bring one Business, one approved Intake, and your current duplicate window. See how Lucidity records duplicate evidence inside a Validation Run, holds ambiguous Leads for review, and keeps each Delivery decision auditable.
Request a Lead Validation walkthrough