Understand what a merge actually destroys

A CRM merge is not a cosmetic cleanup. It collapses two records into one, reassigns related activity, and may discard the losing record's identifiers, field history, or owner trail. The visible result looks tidy, which is exactly why the decision needs evidence. Before anyone clicks merge, the reviewer should be able to explain which record survives, which fields will be overwritten, and how the change can be reversed if the decision is wrong. A Philippines-based CRM administrator can prepare the comparison, identify conflicts, and route the decision to the record owner. The administrator should not merge records merely because they look similar, and should not resolve an ownership dispute by choosing the record with more activity. Similarity is a reason to review, not a reason to act.

Write the survivor rule before comparing fields

The survivor rule should say which record becomes the master and why. Common criteria include the record with the verified legal name, the record tied to the active contract, the record with the authoritative external identifier, or the record designated by the business owner. The rule should be written for the record type, not invented for each case, so different reviewers reach similar conclusions when the facts are similar. Apply the rule to the whole record, not only to the name and email fields. Check the account owner, lifecycle stage, consent or communication preferences, credit terms, territory, and any custom fields that drive routing. A merge that preserves the name but loses the approved communication preference can create a compliance problem while looking like a successful cleanup.

Capture the evidence packet

The packet should include both records as observed, the comparison that shows field-level differences, the related objects that will move, the proposed survivor, and the reason the rule points to that survivor. Record the observation time because CRM records change. If a field is blank on one record and populated on the other, say whether the blank is a confirmed absence or an unverified gap. Include the downstream dependencies that a merge can affect: open opportunities, support cases, invoices, marketing lists, portal access, and integrations that use the record identifier. The administrator may gather this list, but the owner of each dependent system decides whether the merge is safe for that system. A CRM merge that breaks a finance or support link is not a local cleanup problem.

The merge reviewer can say that two records appear to describe the same organization. The reviewer cannot decide that the organization has consented to a new marketing purpose, that a contract applies to the merged entity, or that a credit term should carry forward. Those are owner decisions with legal, commercial, or privacy consequences. The review should separate the factual comparison from the decision and show who approved which part. Where consent or communication preferences conflict, do not default to the more permissive record. Preserve both values, flag the conflict, and route it to the privacy or marketing owner. A merged record that silently adopts the wrong preference is harder to detect later because the original evidence is gone. If the system cannot preserve the source values, record them in the approval packet before the merge.

Work a realistic duplicate case

Two account records share a similar name but use different domains. One has an active contract and a verified billing address; the other has recent activity but no contract and an unverified phone number. The administrator compares the external identifiers, finds that the active contract record carries the approved identifier, and proposes it as the survivor. The recent activity record has two open cases and a marketing subscription that the contract record lacks. The packet lists the proposed survivor, the fields that would be overwritten, the related cases that would move, and the consent conflict that needs an owner decision. The sales owner confirms the account relationship. The privacy owner decides how the communication preference should be handled. Only after both decisions are recorded does the administrator perform the merge, and the post-merge check confirms that the cases and the approved preference survived.

Verify after the merge and sample monthly

Verification means opening the surviving record and the dependent systems, not only confirming that the merge job completed. Check the identifier, the owner, the open cases, the contract link, the communication preference, and the audit history. If the system supports a restore or undo window, record when it closes. If it does not, say so in the packet so the approver understands the reversibility limit. Each month, sample a small set of merges and test the survivor rule, the evidence packet, the approvals, and the downstream checks. Look for merges performed without a recorded rule, conflicts resolved without an owner, and records that lost a required field. A repeated defect may mean the rule is unclear or the merge tool exposes fields in a confusing order. Fix the rule or the tool guidance before coaching individuals.

Sources and limits

NIST Privacy Framework, the Federal Trade Commission's data-security guidance, and the U.S. Government Accountability Office's Standards for Internal Control provide general context for evidence, access, and control design. They do not determine the correct survivor for a specific CRM record or replace the client's legal and privacy review. Sources: https://www.nist.gov/privacy-framework https://www.ftc.gov/business-guidance/privacy-security/data-security https://www.gao.gov/products/gao-14-704g