Same name, same contact? Ask your agent for evidence before merging CRM records

Two “Alex Chen” contacts belong to the same company. An agent merges them, combining two salespeople's activity histories. The list is shorter; the relationship data is wrong.

Matching names—or matching fields—do not necessarily establish one person. AI CRM deduplication works better as a review queue with explicit match rules, counterevidence and missing confirmations. The relationship owner retains the identity decision.

CRM automation guide you can build with Buda starts hygiene with detection. Entity matching needs its own rules: a business key preventing duplicate tasks cannot determine whether two contacts are the same person.

Preserve eight rows before trying to make four

All eight rows are fictional. Addresses use the reserved .example domain and are not contact destinations. No production CRM test was run. The source date is October 18, 2026; actual exports should preserve each row's source system and update timestamp.

A:101 and B:101 have the same numeric ID in different namespaces. They are not one source record. Include both namespace and ID; do not discard a row as a duplicate primary key.

Nor must the sample produce four pairs. Candidate generation, identity verification and merging are separate stages. A pair without useful evidence may stay out of the review queue entirely.

Normalize comparison values, not source truth

Retain email_raw and create a separate comparison value. A conservative copy-only rule trims surrounding whitespace, lowercases the domain and preserves the local part. Whether local-part case can be ignored needs an explicit source and team rule. Under this rule, Priya's values match, but that still creates a strong candidate—not permission to merge.

Do not strip +tag or Gmail dots by default, and do not apply one provider's alias behavior universally. A plausible address is not proof of validity, delivery or ownership. Sending verification email would also expand this read-only task.

Retain raw telephone numbers and their sources. If the country code is unknown, do not infer it from the company address. Matching local-number suffixes are not globally unique. Name spelling, domain and job title help retrieval but do not settle identity individually.

Three labels are more useful than an invented probability

“Strong” does not mean approved. Different employers and emails also do not necessarily mean different people. S04 is an invented explicit confirmation; without equivalent authorized evidence in real work, leave the relationship unknown. Person identity and company affiliation may need different object relationships.

Avoid uncalibrated claims such as “92% likely the same person.” Reviewers need the rule that fired, counterevidence and the next confirmation—not a precise-looking guess.

A pair must carry its provenance

candidate-pairs.csv needs pair ID, both namespaces and record IDs, match-rule version, original and comparison values, source timestamps, supporting evidence, counterevidence, gaps, class and suggested verification role.

A reproducible pair ID can sort the two namespaced identifiers in a fixed order and include the rule version: v1|A:102|B:202. This is a proposed naming convention, not a native Buda idempotency lock. Two runs with the same redacted inputs and rule should return the same pair ID; that acceptance check has not been executed here.

Do not assume pairwise clues are transitive. Evidence connecting A to B and B to C does not automatically prove A equals C. Review shared addresses, historical changes and distinct people before collapsing a group.

conflicting-fields.md retains each original field, source and update time. Priya's departments may reflect a move, different export times or bad entry. The business owner chooses the retained value; the newest timestamp does not win automatically. The agent does not change owner, stage or amount.

review-decisions.csv records confirmed same person, different people or insufficient evidence, with verifier, basis, time and follow-up decision. Keep suggestions separate from human decisions. Unreviewed candidates are not confirmed duplicates.

Identity confirmation is still not a merge plan

CRM records can link to activities, opportunities, tickets, subscriptions and permissions. Without checking primary-record selection, relationship migration and the native undo behavior, do not promise “we can restore it if wrong.”

Keep exports and candidates read-only. Do not connect production write access, delete, merge or transfer ownership. After identity confirmation, let the CRM administrator inspect retained fields and relationship impacts. Actual operations require explicit authorization and verified system behavior. This queue neither replaces the CRM nor claims a tested integration with a named vendor.

Run one read-only pass in Buda

Put authorized redacted exports, field dictionary, rules and necessary confirmation material in Drive. Agent Drive and Space Drive differ in sharing scope; a new Session separates conversation, not file permissions.

Read only the named redacted copies and rules. Preserve namespaces, record IDs and raw values; normalize for comparison only. Produce candidate pairs, field conflicts and a human-decision template with sources, counterevidence and gaps. Do not invent calibrated identity scores, write production CRM, delete, merge, send or change business fields.

Inspect same-name different people, shared inboxes, employer changes and one person with multiple addresses. Verify that each candidate returns to source rows and unconfirmed fields remain blank. File existence does not establish match accuracy.

The RevOps guide addresses broader governance. Start here with one concrete risk: showing which two rows deserve investigation, why and who decides afterward.

Measure reviewed quality, not candidate volume

After human verification, candidate precision can be calculated as confirmed same-person pairs divided by pairs with completed identity verification. Report insufficient evidence separately rather than placing it in the verified denominator. Preserve class and rule version to locate false-positive rules.

That measures the accuracy of submitted candidates, not missed duplicates. Recall needs a separate representative labeled set. Without one, mark it unmeasured. The eight teaching rows establish neither business accuracy nor time savings.

What if several people use one inbox?

Treat it as a contact method, not a unique person. Preserve separate contacts and responsibilities, and verify the CRM's relationship support. Shared email alone must not trigger a merge.

Can someone who changed companies still be the same contact?

Yes, with authorized explicit identity evidence. Handle previous company, historical activities and new affiliation separately. Same-person confirmation does not transfer old opportunities to the new employer.

Who confirms the decision?

The relationship owner verifies identity; the CRM administrator checks links and system operations. Record evidence, role, time, retained fields and next action. Without sufficient support, keep the case unresolved.

Make a bad match easy to challenge

Search for and install an appropriate data-processing Skill in the Buda AI Marketplace. Inspect its matching rules and stops before using redacted copies. The first goal is not a shorter list. It is a defensible candidate with an owner who can say “do not merge.”