Proposed intake policy
A matching value is evidence, not the whole decision.
Adapt these routes to the CRM and the meaning of the record. A source-specific account ID does not automatically identify the same entity in another system.
| Evidence at intake | Route | Action |
|---|---|---|
| Same trusted source ID within the same source and record type | Known-record update candidate | Check permitted fields and conflicts; use the supported update operation. Do not silently replace ownership. |
| Same personal email but conflicting identity details | Review | Check whether the address is shared, reassigned or incorrectly captured before combining history. |
| Similar name or shared company domain | Candidate only | Several people or entities can share these values. Require corroborating evidence. |
| Different company numbers or missing identifiers | Hold automatic merge | Check jurisdiction, entity type and possible errors; a difference is a conflict to investigate, not proof by itself. |
Inspect every entry path
Find where the extra records are created.
Forms, imports and integrations may apply different matching rules. HubSpot documents a company-domain deduplication exception for API-created companies; do not assume that a rule observed in an import also covers an integration.
That product behaviour is documentation-based, not an authenticated account test. In a custom intake path, test repeated submissions and two creates arriving together. A search followed by create can race when both requests see no existing record.
List manual entry, forms, imports, integrations and enrichment paths, with their actual matching rules.
Define each record type and the source and scope of any identifier used to update it.
Set permitted field updates, ownership conflicts and a named review route.
Record the decision and source IDs so a rejected match or mistaken update can be investigated.
Comparison policy
Keep identity, field updates and ownership separate.
These are proposed controls, not a measured claim that three rules catch most duplicates. Validate them on examples from the actual intake paths.
Original and comparison
Normalise only under a documented rule
Retain the original value. Email domains are case-insensitive, but RFC 5321 requires preserving mailbox local-part case. Do not blindly lowercase every address or strip dots and plus-tags across all providers.
Name cleanup can help find candidates, but removing a legal suffix can hide a meaningful difference. Normalising a phone number does not prove who currently uses it.
Action
An update is not a merge
Updating a known source ID changes an existing record. Merging combines two existing records and can affect activities, associations and field values. Check product-specific behaviour before approving it.
HubSpot documents that records cannot be unmerged. Retain a pre-change export and decision log, but do not promise that an export is a one-click restoration of every association or automation effect.
Responsibility
Resolve ownership deliberately
A repeated submission should not silently reassign an account because one source sends a different owner. Show the conflict and apply the agreed authority rule.
There may be different roles for account, opportunity and service ownership. Resolve them for the record type rather than imposing one owner field across every workflow.
Fictional review examples
Keep these candidates separate until the evidence is checked.
The names, identifiers and decisions below are invented examples of a review policy. They are not model accuracy results, observed CRM records or instructions to merge real people.
Maya and Alex both use team@example.com.
Why a simple rule fails: An exact address can be a shared inbox, not one person.
Proposed next step: Keep person records separate; inspect the role of the shared address.
John Smith and Smith, John have similar name tokens.
Why a simple rule fails: A reordered name may be the same person or a different person with that name.
Proposed next step: Use corroborating identity evidence; a token score is not permission to merge.
Cedar Ltd and Cedar Services Ltd have different registration numbers.
Why a simple rule fails: Suffix removal hides differences; number scope, jurisdiction and data errors matter.
Proposed next step: Check entity evidence and the conflicting values before deciding.
Two submissions carry source-A contact ID C-204.
Why a simple rule fails: A repeated source ID suggests an update only within its trusted source and record type.
Proposed next step: Check allowed updates, concurrent handling and ownership; do not combine unrelated records.
Implementation and checks
Test the policy before turning on automatic actions.
Use labelled examples of both true duplicates and separate entities. Record false merges, missed duplicates and review effort. No accuracy or duplicate-reduction rate is assumed here.
01
Map the entry paths
Record what manual, import, form and integration paths actually do, including product-specific matching exceptions.
02
Test the difficult pairs
Include shared inboxes, common names, changed identifiers and conflicting company details. Choose which cases can only be reviewed.
03
Test retries and concurrent creation
Submit the same event twice and two requests together in a safe test environment. Check that the chosen supported identifier or concurrency control actually prevents extra records.
04
Review the outcomes
Count confirmed duplicates, false merges, missed cases and queue age. Record the reviewer and evidence; do not infer prevention from the number of merges alone.
Before the gate
Prevention and backlog cleanup are different jobs.
A proposed intake control does not establish that every existing record is correct. Inspect the backlog separately and retain uncertain pairs for review rather than merging them to improve a count.
Use a separate audit to inspect the records already present; prevention alone does not measure the backlog.
Run a CRM data audit in a day ->Fictional policy illustration
Example decisions, not a live CRM connection.
These fixed messages illustrate the proposed review policy. They do not read customer records, perform merges or demonstrate measured accuracy.
