Contact Deduplication

Status: On request. A Data Enhancement operation. Writes to the CRM.

Two matching strategies

Duplicates in a CRM do not have one shape, so matching does not use one signal. The two strategies below are separate passes with different evidence and different survivor rules. Which of them applies to a given portal is a configuration decision made before the pass runs.

Strategy one: normalised name with a company gate

Contacts are grouped by exact normalised full name, lowercased with whitespace collapsed. Records with a blank name are never grouped, so they cannot match each other.

Within a group, a record is only eligible to merge into another if its normalised company matches, with both values non-blank. That gate exists to prevent the obvious failure of this approach: two different people who happen to share a name. Where the company does not match, the record is counted and skipped rather than merged.

Strategy two: profile identity

The name-and-company approach cannot pair the dominant duplicate shape in many portals: the same person ingested twice, once under a former employer and once under the current one. The company differs, so a company gate can never match them.

The second strategy keys on the normalised public LinkedIn profile slug, which is a stable per-person identifier that survives a job change. Sales Navigator URLs are deliberately rejected rather than matched on: those handles are per-viewer identifiers, not stable public profile identifiers, and treating them as identity would merge on a value that differs between viewers.

The survivor is the record whose email domain matches its own company name, on the reasoning that this is the record whose address is actually valid at the company it claims. Where more than one record qualifies, the most recently created wins, because that is the current employer. Free and webmail domains are excluded from the domain-matches-company test, and common company suffixes are stripped before comparison so that a legal suffix does not defeat a match.

Skip conditions

A pass is written to decline rather than guess. Groups where no survivor can be established are skipped whole. Candidates whose corroborating signal does not match are skipped and counted, and the counts are reported with the run so a skipped record is visible rather than silent.

Before and after a merge

A snapshot of the affected records is taken before a merge pass runs, and a second snapshot after it completes. Both are retained outside the CRM. Every merge is recorded with both record identifiers.

A merge is not an undo-able operation. The platform merge API combines two records into one, and there is no call that separates them again. The safeguard is the pre-merge snapshot and the approved scope, not reversal. This is the reason a pass is scoped and dry-run first rather than run broadly.

Configurable and client-specific policy

Which strategy runs, what counts as corroborating evidence, and which record wins are policy decisions configured for an environment, not fixed Mixbound rules. One client environment treated the absence of an email address as the marker of the duplicate and the presence of one as the marker of the survivor. That was correct for the shape of that portal and is not a universal rule; a portal where both records carry an email needs a different survivor rule, defined before the pass runs.

Limitations worth stating

Matching is deterministic, so it will not find a duplicate that carries no shared signal: no common name, no common company, no profile identity. A pass reports what it could not resolve rather than lowering the threshold to reach a number.

Determinism

No part of this calls a language model. The same records and the same configuration produce the same pairs every time.