Bulk Sync Deduplication and Merge Triage Playbook

Use this playbook when a spreadsheet-to-CRM bulk sync, or a shared lead intake, creates duplicate contacts or leads, drops a field on conversion, or lets two people work the same record.

Typical triggers:

• A bulk update from a sheet creates second copies of contacts that already exist [2420].
• The same lead is worked by two agents because nobody was notified it already existed [2383].
• A field present on the source record is empty after a Lead converts to a Contact [2346].
• Two people edit one record at once and overwrite each other's changes [2383].

Classify before you touch anything. The blast radius differs sharply by cause.

Keep roles generic and named up front so escalation is not improvised.

• Data / sync owner: runs this triage, owns the decision to pause the sync.
• CRM / automation escalation: owns duplicate detection, the match key, and conditional field automations; called when the fault is in the write path itself.
• Comms lead: owns the message to agents and to the client when duplicate outreach has already gone out.

Work read-only first. Never re-run a live sync to reproduce; dry-run against a copy.

[ ] 1. Dry-run the match against a COPY, not production. A live re-run
       can multiply records again before you diagnose anything. [2420]
[ ] 2. Confirm duplicate detection runs BEFORE the write. If records
       are written first and deduped after, the damage is done. [2420]
[ ] 3. Inspect the MATCH KEY. A key too loose or on the wrong field
       fails to match a record already there. [2420]
[ ] 4. Check field validation and conditional automations. Confirm the
       type-flip and salutation-from-gender rules fire as intended
       and do not corrupt the match. [2420]
[ ] 5. Check whether CONVERSION drops a field. Convert a Lead to a
       Contact on a copy; confirm every source field survives. [2346]
[ ] 6. Check whether two people can work one record. Look for a
       duplicate-property notification and whether claiming hides
       the lead from other agents. [2383]

Match the symptom to the cause. Each branch points to one mitigation.

Apply the least invasive fix that resolves the diagnosed branch. Do not stack fixes you have not diagnosed.

1. Fix the match key so duplicate detection fires before the write. Point detection at the field that reliably identifies an existing contact so a bulk edit updates the record in place instead of creating a copy. Detection before write is what stops bulk edits from multiplying records [2420].
2. Add merge handling for detected duplicates. Once detection recognizes an existing contact, handle the merge in the same workflow that auto-creates or updates contacts, not in a manual cleanup pass [2420].
3. Add field validation plus a matching field and formula sync. Validate incoming data and run conditional automations, such as flipping a contact from Buyer to Owner and setting salutation from validated gender [2420]. Where a value drops on Lead-to-Contact conversion, add a matching field on both entities and a formula sync so it carries over [2346].
4. Gate claiming of shared records. Give each lead an auto reference ID and a pool view; let an agent self-assign to claim, converting it to an owned lead and hiding it from other agents while admins still see it. Lock fields on claimed leads so edits need manager consent, and fire a duplicate-property check that notifies managers and agents when a lead already exists [2383].

Escalate to the CRM / automation owner when:

Verify against a copy first, then against controlled live behavior.

• Dry-run the sync against a copy; confirm existing contacts update in place with no new duplicates [2420].
• Convert a Lead to a Contact; confirm every field, including the one that was dropping, carries over [2346].
• Have one agent claim a pooled lead; confirm it disappears from another agent's view while admins still see it, and that the duplicate-property notification fires [2383].

Capture, in the incident record:

• The match key in use and the field it should key on [2420].
• A before/after of a converted record showing the field that dropped and now survives [2346].
• The claim and duplicate-notification behavior on a shared lead [2383].

Comms template for agents and client:

We found a data-sync issue that created some duplicate records and, in a few cases, meant one contact was worked by two people. We have corrected the sync and merged the duplicates. If you were contacted twice, we apologize; no action is needed on your side.

Run a retro and link it from the incident record. Lock in prevention:

• Duplicate detection runs before the write, keyed on a field that reliably identifies an existing contact [2420].
• Merge handling on every detected duplicate, not a manual cleanup pass [2420].
• A matching field plus formula sync on any value that must survive conversion [2346].
• Claim-and-hide, field locking, and a duplicate-property notification on every shared record two people can race for [2383].