What is the difference between a record merge and a delete?
A delete removes a record and (depending on the system) its child records from the active base. The data is gone or hidden, and any related history goes with it. A record merge preserves the data: the losing record retires, its field values reconcile into the survivor, every child record reparents onto the survivor, and the lineage log keeps the retired IDs resolvable. Teams reach for Delete when they meant Merge and silently destroy sales history every time.
What is the difference between a record merge and a deduplication?
Deduplication is detection: the matching engine scores pairs or clusters of records to decide which ones describe the same real-world entity. The output is a list of duplicate sets with a confidence score. A record merge is the action that resolves one of those sets into a single authoritative record. Dedupe without a merge workflow produces nothing but a backlog; a merge workflow without dedupe never has anything to run on.
How does a CRM pick which record survives a merge?
The default rule varies by system. Common defaults pick the oldest record (to preserve the earliest created date and audit history), the record with the most activity, the record with an assigned owner over one without, or the record with the highest lifetime value. The user running the merge can override the default, and the surviving ID is logged with the override reason so the audit trail can tell the difference between policy and manual choice.
What happens to related records (activities, opportunities, notes) during a merge?
Every related child record reparents from the losing records onto the surviving record before the merge completes. Open and closed opportunities, tasks, calls, emails, notes, files, campaign memberships, custom child objects, and support tickets all repoint to the survivor in a single transaction. A merge that leaves child records on the retired IDs has corrupted the base, not cleaned it, and should fail and roll back rather than commit.
What is field-level merge?
Field-level merge means the CRM reconciles each field independently across the duplicate set rather than copying one row wholesale. The merge might pick the email from one record, the title from another, the industry from a third. Default rules (most recent, longest value, earliest created, populated over blank) propose a winner per field, and the user can override. This is the only merge model that produces a complete record from partial duplicates.
Can a record merge be undone?
Yes, within a bounded window on most modern CRMs. Unmerge restores the losing records to active status, moves the reassigned child records back to their original parents using the reassignment log, and reverts the survivor's field values to the pre-merge state. The window is usually thirty to ninety days. After the window closes the merge is permanent, but the lineage log remains queryable so retired IDs still resolve.
What is a merge audit trail?
The merge audit trail is the log the system writes alongside every merge. It records the duplicate set, the surviving ID, every field decision with old-value and new-value and the rule that picked the winner, every child record that reparented, the user and timestamp, and the match confidence of the set. The audit trail is how RevOps debugs scoring drift, how compliance answers a right-to-know, and how admins reverse a bad merge inside the unmerge window.
Should a sales rep be allowed to merge records?
It depends on the record type and the governance model. Most teams let reps merge contacts under accounts they own, with field-level review required, because the rep has the context to pick the right title or phone. Most teams restrict account and deal merges to a RevOps or admin role, because the downstream impact on pipeline reporting and territory assignment is harder to see. The permission model should be explicit and the audit trail should name the merging user either way.
