Signal-based prospecting creates a duplication problem that ordinary lead imports do not fully address.

The same person can appear in several comment threads, change companies, use multiple email addresses and already exist in the CRM. The same company event can arrive from several providers. Each observation can then create a separate task or outreach step.

Lead workflow deduplication is the set of identity, event and action controls that prevents this from becoming duplicate records and visibly repetitive contact.

There are four different duplicates#

Event duplicates#

Several sources describe the same underlying event.

Example: a funding round appears in a company announcement, a news feed and an enrichment provider.

Person duplicates#

Several records refer to the same individual.

Example: one record uses a LinkedIn profile, another a work email and another an old CRM contact.

Company duplicates#

Several entities refer to the same commercial account or company group.

Example: example.com, example.co.uk, a subsidiary and a CRM account with an abbreviated name.

Action duplicates#

Different valid records try to create the same business action.

Example: two independent signals both add one prospect to first-touch outreach on the same day.

Solving only person records is not enough. A clean database can still produce duplicate tasks.

Build canonical identifiers#

For people#

Useful identifiers include:

  • Normalised LinkedIn profile URL
  • Verified work email
  • Internal CRM contact ID
  • Provider person ID
  • Full name plus company as a cautious fallback

Do not rely on email alone. Addresses change, aliases exist and some sources only expose profiles.

For companies#

Use:

  • Normalised primary domain
  • CRM account ID
  • Registered entity or provider ID where relevant
  • Parent-child relationships
  • Known alternate domains

Company-name fuzzy matching can suggest candidates, but it should not automatically merge common names without corroboration.

For events#

Create an event fingerprint from stable properties such as:

  • Event family
  • Subject person or company ID
  • Effective date or time bucket
  • Normalised object, topic or announcement
  • Original source identifier

Several observations can then link to one canonical event while retaining their provenance.

Normalise before matching#

Small formatting differences create false uniqueness.

Normalise:

  • Lowercase domains and emails
  • Remove URL tracking parameters
  • Standardise LinkedIn URL variants
  • Convert company suffixes consistently
  • Parse names into comparable forms while preserving the original
  • Convert timestamps to a common zone
  • Map provider taxonomies into your own event families

Keep raw values alongside normalised values. Normalisation is an interpretation, and you may need to debug it.

Use deterministic matching first#

Start with high-confidence rules:

  1. Same CRM ID
  2. Same normalised LinkedIn URL
  3. Same verified email
  4. Same trusted provider ID
  5. Same company domain plus strong person attributes

Use probabilistic or fuzzy matching only when deterministic identifiers are absent. Store match confidence and send ambiguous merges to review.

False merges can be worse than duplicates. Two people with the same name at one company should not share contact history or suppression state accidentally.

Not every related record should become one object.

  • Observations link to a canonical event.
  • Historical employment links a person to a former company.
  • Subsidiaries link to a parent account.
  • Several contact methods link to a person.

Merging destroys boundaries. Linking preserves the relationship while keeping original evidence.

Design idempotent workflow stages#

An idempotent step produces the same result when the same input is processed again.

For each stage, define an idempotency key.

Examples:

  • Capture: source ID plus source event ID
  • Enrichment: person ID plus provider plus data version
  • Qualification: entity ID plus rule-set version plus active event window
  • Task creation: person/account ID plus play ID plus time window
  • Outreach enrolment: contact ID plus sequence ID plus eligibility period

Store the result against the key. A retry should return or update the existing object instead of creating another.

Deduplicate actions across signals#

Suppose a prospect changes role on Monday and comments on a relevant post on Tuesday. Those are genuinely different signals, but they may justify one combined review task rather than two messages.

Use an action window:

  • Group active evidence by person, account and play
  • Update an open task when stronger evidence arrives
  • Notify the owner only when priority materially changes
  • Close or expire the task according to policy
  • Create a new action only after the cooldown or a distinct business reason

This allows signal stacking without action duplication.

Carry suppression through every merge#

Suppression data has priority over enrichment excitement.

Check:

  • Global and channel-specific opt-outs
  • Recent direct contact
  • Active sequences
  • Open opportunities
  • Customer status
  • Account ownership
  • Legal or contractual restrictions
  • Manual “do not contact” notes

When two person records merge, combine suppression conservatively. Do not let a new email address bypass an opt-out associated with the same person.

Handle job changes explicitly#

A person changing company creates a new relationship, not a new human.

Maintain:

  • Canonical person ID
  • Employment records with effective dates
  • Contact methods tied to the relevant employment
  • Account ownership and relationship history
  • Whether previous consent or suppression applies to the new context

Do not keep emailing an old company address. Do not automatically assume a relationship or lawful basis transfers unchanged to the new employer.

A practical deduplication sequence#

  1. Store the raw source record.
  2. Normalise identifiers.
  3. Match or create the canonical event.
  4. Match or create the canonical person.
  5. Match or create the canonical company.
  6. Link person, employment, company and event.
  7. Apply fit, recency and signal rules.
  8. Check suppression and ownership.
  9. Find an existing open action for the person/account/play.
  10. Update that action or create one with an idempotency key.
  11. Record every merge, link and decision.

The audit trail should show which raw records produced the final action.

What to do with uncertain matches#

Create three bands:

  • Auto-match: strong deterministic identifier
  • Review: plausible match with several supporting fields
  • Keep separate: insufficient evidence or contradiction

Expose the fields that agree and disagree. A reviewer should see why the system proposed the match.

Avoid a forced match merely to produce tidy metrics. Unknown identity is an honest state.

Metrics that reveal deduplication health#

Track:

  • Raw-to-canonical event ratio
  • Person and company duplicate rate
  • Percentage of matches by rule
  • Manual merge and split rate
  • Action updates vs new actions
  • Repeat outreach prevented
  • Suppression conflicts
  • Stale contact methods blocked
  • False-merge incidents
  • Records with no stable identifier

Monitor by source. One provider or collection method may create most of the instability.

Common mistakes#

Matching on name alone#

Names are neither unique nor stable. Use them as supporting evidence.

Deduplicating only at import#

Identity changes and new signals arrive continuously. Match at each relevant workflow stage.

Deleting raw source records#

Keep provenance. A canonical record should not erase the evidence used to create it.

Creating a task for every signal#

Signals should enrich a decision object. They should not automatically become separate rep work.

Letting retries create new side effects#

Network and provider failures will cause retries. Idempotency keys turn them into safe repeats.

Deduplication is part of the customer experience#

Duplicate records look like an operations problem inside the company. To a prospect, they look like a company that does not listen.

A reliable lead workflow resolves identity cautiously, groups evidence intelligently, honours suppression and creates one coherent action. That is not back-office polish. It is a prerequisite for scaling signal-based outreach without scaling avoidable mistakes.

Keep exploring

TWL Signals

Turn market attention into a qualified prospect feed.

Monitor the people and companies your buyers already follow, keep the original context, enrich the profiles and route only the strongest matches into outreach.

Start building your signal workflow