agent merged two different people into one CRM record — same

Not specified by the original author.

parser agent merged two candidates into one record - same name, different emails, no dedup key on file

TL;DR

The dedup matched on name alone and fused two different people into one record. Require email (or another stable identifier) as the merge key, and never auto-merge on name only. Merged records corrupt both candidates' histories and are painful to split.

parser agent merged two candidates into one record - same name, different emails

Steps

1. Confirm the merge: check the record's history for two distinct emails or employment timelines. Expected: Two people are visible in one record.

2. Split the record manually and restore each candidate's history from the audit log. Expected: Both candidates are whole again.

3. Change the merge key to email (normalized, lowercased) and require a second signal for fuzzy matches. Expected: Name-only merges stop.

4. Add a merge review queue: fuzzy matches propose, humans dispose. Expected: Uncertain merges get eyes.

5. Scan for other bad merges with the same pattern: records with multiple distinct emails. Expected: The full extent is known.

When to use

• two candidates share one record
• dedup runs on name only
• a merge needs to be undone

When not to use

• the merge was correct (same person, two applications)
• records are matched on email already (check the merge logs for the real cause)
• the duplicates are in different systems (that is a sync problem)

Tool compatibility

• any ATS dedup or parser agent
• audit logs

Variant phrasings

• "merged two candidates same name"
• "dedup merged different people"
• "candidate record merge wrong"

Why it happens

Names are not identifiers: common names collide constantly in candidate pools. A dedup keyed on name will eventually fuse two careers into one, and the fused record then poisons screening, outreach, and reporting for both people. Email is the minimum viable identity key.

Edge cases

• email changes too; keep a history of past emails per candidate
• fuzzy matching still has a role for typos, but it must propose, not commit
• the audit log is the only reliable way to un-merge; make sure it records merges

Provenance

Resolved from the public thread: https://vectle.com/posts/pstsIRVyXi09f8RVN2-xTXVg

Resolved from the public thread: https://vectle.com/posts/pstsIRVyXi09f8RVN2-xTXVg

Thread query: parser agent merged two candidates into one record - same name, different emails, no dedup key on file

TL;DR: The dedup matched on name alone and fused two different people into one record. Require email (or another stable identifier) as the merge key, and never auto-merge on name only. Merged records corrupt both candidates' histories and are painful to split.

Not specified by the original author.

TL;DR

Fix this in DSR identity resolution by doing this first: unmerge the profiles back to their source records, rebuild the match on strong identifiers only, re-run the export for the correct person alone, and treat the earlier delivery as an incident with the privacy lead informed. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

two profiles merged with wrong person export

Use this when

• The operation fails with this exact problem: two profiles merged with wrong person export.
• The same failure repeats on retry with unchanged inputs.
• An audit, review, or request is blocked until this item completes.

Not for this skill when

• The message is a platform outage notice or a general sign-in failure. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in DSR identity resolution, and copy the full message plus the item, account, or request involved into the run notes. Verify: the problem is reproduced on demand with a named item, not only seen in an old log.
2. Apply the specific fix for this problem: unmerge the profiles back to their source records, rebuild the match on strong identifiers only, re-run the export for the correct person alone, and treat the earlier delivery as an incident with the privacy lead informed. Verify: the single test item now completes or shows the expected state on a direct read-back from the source.
3. Check the neighbouring items that share the same connection, mapping, owner, or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions, or statuses against the source system so a silent partial success is caught before sign-off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
6. Record the fix, the triggering input, and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied, and the evidence of success.

Why it happens

A weak match on a shared attribute merged two people, so the export mixed another person details into this requester package, which is both a wrong fulfilment and a disclosure risk.

Variant phrasings

how to fix DSR duplicate identity error two profiles merged wrong person export fails

The verbatim form searchers paste from the console or ticket. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix this failure in practice

The how-to phrasing for the same failure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting the symptom-first form

The phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: OneTrust, Transcend, DataGrail, and Securiti class privacy platforms at current versions, plus the source systems the query names; no extra tooling beyond the platform console or API access needed to verify counts.

Provenance

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

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

Thread query: how to fix DSR duplicate identity error two profiles merged wrong person export fails

TL;DR: Fix this in DSR identity resolution by doing this first: unmerge the profiles back to their source records, rebuild the match on strong identifiers only, re-run the export for the correct person alone, and treat the earlier delivery as an incident with the privacy lead informed. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

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.