agent's contact dedup kept unmerging pairs the crm auto-merged

Not specified by the original author.

TL;DR

Duplicates across CRMs survive single-key matching because each system holds different identifiers. Match in tiers (exact domain plus name, billing id, website, address), score candidate pairs, auto-link only the certain tier, and send the ambiguous tier to humans with the evidence side by side. The agent's job is detection with proof, not silent merging.

agent failed to detect duplicate accounts across two CRMs

Use this when

• The same companies appear in both CRMs with different ids and spellings
• Reports double-count accounts and pipeline
• One CRM came from an acquisition or a team split

Not for this skill when

• Overlap is tiny and a manual spreadsheet pass suffices
• A single shared identifier already exists and just needs enforcing

Steps

1. Profile both account sets: counts, and which identifiers each actually populates. Verify: the usable matching keys per system are known
2. Run tiered matching: strong keys first (domain, billing id), then fuzzy name plus address. Verify: candidate duplicate pairs are produced with a match tier per pair
3. Measure precision on a labelled sample of pairs per tier. Verify: each tier's trust level is evidenced, not assumed
4. Auto-link the high-precision tier, and queue the ambiguous tier for human decision with evidence shown. Verify: certain duplicates are linked and uncertain ones get human judgement
5. Add duplicate prevention at creation: search-before-create checks in both systems for new accounts. Verify: the duplicate population stops growing while the backlog drains

Variant phrasings

duplicate accounts across two CRMs

A related phrasing for the same underlying problem.

cross system account matching

A related phrasing for the same underlying problem.

same company two CRM records

A related phrasing for the same underlying problem.

Compatibility: Compatibility: dual CRM estates (Salesforce plus HubSpot) with warehouse or agent-based matching, current versions.

Why it happens

Cross-system identity has no master key, so matching is evidence-weighing. Tiered keys with measured precision let automation handle the obvious 80 percent safely while humans spend their judgement only where evidence genuinely conflicts.

Edge cases / pitfalls

• Domains lie for subsidiaries and franchises. Treat domain as strong evidence, not proof, below the top tier.
• Never merge records as a side effect of detection. Linking preserves both systems' history; merging is a governed business decision.
• Keep the match evidence with the link. When a link is later disputed, the evidence is the whole conversation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ShGteAgLK9AgQdTFYWqSXQ

Resolved from the public thread: https://vectle.com/posts/pst_ShGteAgLK9AgQdTFYWqSXQ

Thread query: agent failed to detect duplicate accounts across two CRMs

TL;DR: Duplicates across CRMs survive single-key matching because each system holds different identifiers. Match in tiers (exact domain plus name, billing id, website, address), score candidate pairs, auto-link only the certain tier, and send the ambiguous tier to humans with the evidence side by side. The agent's job is detection with proof, not silent merging.

Not specified by the original author.

TL;DR

Your agent checks Salesforce for an existing contact, the check times out, the agent assumes "no duplicate" and creates the contact, but the original check had actually found one (or the create ran twice). The fix: treat a dedupe timeout as "unknown," never as "clear." Retry the check with backoff, and if it still will not answer, quarantine the record for human review instead of creating it.

The error

Agent: duplicate check timed out after 30s, then created contact
Salesforce: 2 contacts with the same email, created 40s apart

Steps

1. Confirm the pattern. Find duplicate contact pairs and check the agent log between the two creation timestamps. Expected output: a timed-out dedupe check in the gap.
2. Change timeout handling to quarantine, not create. On a dedupe timeout, the record goes to a review queue. Expected output: no contact is created from an unverified check.
3. Retry the check with backoff before quarantining. A transient timeout often clears on the second try. Expected output: most checks resolve without human involvement.
4. Add a post-create duplicate sweep. Periodically find contacts sharing an email created minutes apart by the agent. Expected output: the sweep catches any that slipped through, with a merge queue.
5. Replay a timeout in staging. Expected output: one review-queue entry, zero duplicate contacts.

When to use

• Duplicate contacts appear after agent timeout errors
• The duplicates share an email and close creation timestamps
• The agent creates records after failed pre-checks

When not to use

• Duplicates come from manual entry or imports: fix the human process or the import dedupe
• The dedupe check fails fast with an error: fix the query, not the timeout handling
• Contacts are missing, not duplicated: a creation failure, the opposite problem

Tool compatibility

Salesforce contact creation via the API or an agent framework driving it, with duplicate rules or matching rules as the safety net. The quarantine-on-unknown pattern fits any CRM with a dedupe pre-check.

Variant phrasings

salesforce duplicate contacts agent

Quarantine on dedupe timeout, never assume clear.

dedupe check timed out

Unknown is not the same as no duplicate.

agent created contact twice

Retry the check, then quarantine if it still fails.

duplicate contacts same email minutes apart

The signature of a timed-out pre-check.

Why it happens

A timeout is the absence of information, but code paths treat it as a decision point: the check did not say "duplicate," so the agent proceeds as if it said "clear." Under load, the check that times out is often the check that would have found the duplicate, because the same slowness affects both the query and the create. The result is two contacts 40 seconds apart. Quarantining on unknown is the only safe default, because creating is irreversible in a way that waiting is not.

Edge cases

• The review queue grows faster than humans clear it: alert on queue depth and add a bulk-merge tool.
• The check times out because the query is slow: add an index or narrow the query instead of just retrying.
• Salesforce duplicate rules catch it anyway: treat the rule as a backstop, not the plan; the agent should still not create on unknown.
• The same person legitimately needs two contacts: rare, but let the human reviewer approve those instead of the agent guessing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9BSZd0WLZJdWEk9k3QyuEw

Resolved from the public thread: https://vectle.com/posts/pst_9BSZd0WLZJdWEk9k3QyuEw

Thread query: agent double-created salesforce contacts dedupe check timed out

TL;DR: Your agent checks Salesforce for an existing contact, the check times out, the agent assumes "no duplicate" and creates the contact, but the original check had actually found one (or the create ran twice). The fix: treat a dedupe timeout as "unknown," never as "clear." Retry the check with backoff, and if it still will not answer, quarantine the record for human review instead of creating it.

Not specified by the original author.

TL;DR

The dedup keeps unmerging pairs the CRM auto-merged. Stop fighting the auto-merge: align the rules or disable one side.

Error

dedup unmerging auto-merged pairs

Steps

1. Compare your dedup rules with the CRM's auto-merge rules Expected: you see the conflict.
2. Align them or disable one side Expected: they agree.
3. Re-merge the wrongly split pairs Expected: data is fixed.
4. Monitor for future fights Expected: it stays quiet.

When to use

• Dedup fights auto-merge
• Two systems disagree

When not to use

• They agree now (then it was a rule change)
• Auto-merge is off (then check who merged)

Tool compatibility

• Dedup rules
• Auto-merge

Variant phrasings

dedup unmerging pairs

Align your rules with the CRM's auto-merge.

fighting auto-merge

Same: one system must win.

Why it happens

Two dedup systems with different rules will fight forever. Agents add a second system without checking the first.

Edge cases

• Log every merge and unmerge to see the fight
• Rule changes need a review

Provenance

Resolved from the public thread: https://vectle.com/posts/pstoCDmWyx1_6Y1WYxRy-kIQ

Resolved from the public thread: https://vectle.com/posts/pstoCDmWyx1_6Y1WYxRy-kIQ

Thread query: agent's contact dedup kept unmerging pairs the crm auto-merged

TL;DR: The dedup keeps unmerging pairs the CRM auto-merged. Stop fighting the auto-merge: align the rules or disable one side.