CRM Data Cleanup: Merge Records Without Erasing Local Context

# CRM Data Cleanup After an Acquisition — SOP

## Purpose and scope

Prepare reviewed CRM merge and correction proposals after an acquisition without erasing source identity, consent or local context. This procedure covers profiling, candidate detection, human review, staged execution and reconciliation. It does not authorize collection of new personal data, legal conclusions, consent changes or an unattended destructive merge.

## Owner, trigger and output

- **Owner:** named CRM data owner.
- **Trigger:** approved cleanup scope and source snapshots are available.
- **Output:** reconciled change ledger, unresolved exception queue and retained rollback evidence.

## Prerequisites

1. Approved purpose, fields, systems, access roles and retention rules.
2. Read-only source snapshots with counts and stable record identifiers.
3. Field and status mapping, including values that must remain source-specific.
4. Duplicate rules, confidence bands and human approval authority.
5. Tested restore or rollback route in a non-production rehearsal.

## Procedure

1. Profile record counts, missing keys, field values, relationships and active automations by source.
2. Normalize comparison values in a staging copy; never overwrite the original source snapshot.
3. Generate candidate pairs with the matched fields and reasons visible.
4. Reject automatic merge when identity conflicts, consent/privacy state differs, active opportunities conflict, or related records cannot be mapped safely.
5. Have the data owner approve the surviving record, field-level values and relationship treatment.
6. Execute a small reviewed batch with an idempotency key per approved proposal.
7. Reconcile source, target and change-ledger counts; sample every exception class.
8. Stop on an unexpected deletion, relationship loss, consent change or unmatched count.
9. Publish unresolved cases to a named queue and retain rollback evidence.

## Exceptions and approvals

Potential shared inboxes, household records, changed names, conflicting account ownership, active deals, suppression/consent differences and portal users always require human review. Only the named data owner may authorize destructive execution.

## Audit record and revision log

Retain scope, rule version, source snapshot identifiers, candidate reason, approver, execution identifier, before/after record keys, reconciliation result and rollback outcome. Review after every batch and revise the rules only through a new tested version.

# CRM Data Cleanup After an Acquisition — Workflow Blueprint

## Trigger and termination

- **Trigger:** an approved cleanup batch references immutable source snapshots and rule version.
- **Success:** every approved proposal has one verified target state and a complete change record.
- **Safe stop:** any unapproved proposal, integrity mismatch, relationship loss, consent/privacy conflict or unavailable rollback route.

## Data contracts

Input: source system, source record ID, entity type, permitted comparison fields, consent/privacy state, related-record counts, active-work flags and snapshot ID. Never include secrets. Output: candidate ID, matched reasons, proposed survivor, field decisions, relationship plan, approval, execution status and reconciliation evidence.

## Ordered steps

1. **Code — validate batch:** check scope, snapshot, rule version and unique business keys.
2. **Code — normalize in staging:** produce comparison values without altering source records.
3. **Code — propose candidates:** emit reasons and confidence; do not merge.
4. **Human — decide identity and fields:** approve, reject or request evidence. Privacy, consent and active-work conflicts cannot auto-pass.
5. **Code — execute idempotently:** use the candidate ID plus approval version; a retry returns the prior result.
6. **Code — reconcile:** compare counts, relationships, required fields and change ledger with the expected state.
7. **Human — close exceptions:** data owner resolves or defers every unmatched case.

## Failure, retry and rollback

Retry only after reading the candidate's effect state. If the target is unknown, reconcile before another write. Stop the batch when a critical invariant fails. Restore from the approved snapshot or reverse through the recorded field and relationship changes where the actual CRM supports that tested method.

## Permissions and tests

Separate read, proposal, approval and destructive-write roles. Test exact duplicates, likely matches, false positives, shared contact details, conflicting consent, active opportunities, missing keys, repeated delivery, partial write and rollback. Acceptance requires no unauthorized merge, no lost required relationship, complete change evidence and matched reconciliation counts.