The access, ownership, logging and rollback questions to settle before a CRM deduplication project, so it clears security and RevOps review.
Rarely in full, and that is the point of settling this first. Most platforms do not offer a native unmerge, so reversal means recreating the losing record from a log you kept and reparenting its activity. Anything that depended on the old record identity, such as reporting history or external integrations keyed to it, may not come back cleanly.
Because it needs broad write access to the system holding your customer data, and because a bad rule at scale is a data loss event rather than an inconvenience. Time bounded named access, a sandbox proof, and a written rollback plan answer most of what a reviewer will ask.
An intake control, which is the step most cleanup projects skip. Validation at point of entry, or a check against the matching rule before a record is created. Without it you are buying roughly two quarters of clean data and will be back where you started.
No. Queue them for human review and agree who clears the queue before the project starts. Auto merging on low confidence is how a real account gets absorbed into the wrong parent, and that is the failure that loses trust in the whole programme.
A named person in RevOps who understands how the business actually sells. Not the CRM administrator by default and not the consultant. Rules need tuning as segments and naming conventions change, and an unowned rule set degrades quietly.
A deduplication project touches the system your revenue team lives in. The questions that stall it at approval are not technical: who can change what, what gets logged, and how a bad merge is undone. Settle those first and the work gets signed. Leave them and the project waits while IT and RevOps negotiate in email.
The access, ownership, logging and rollback questions to settle before a CRM deduplication or customer matching project, so it clears security and RevOps review.
Before a CRM cleanup, four things need agreeing: who holds write access during the work, what is logged, how a wrong merge is reversed, and who owns the rules afterwards. Merges are hard to undo once activity history is reparented, so the rollback plan has to exist before the first merge runs, not after.
Will this integrate safely, and what happens if it goes wrong?
Most of the review time goes here, and most of it can be settled in one conversation if the answers are written down first.
Named accounts with an end date, not a standing integration user that survives the project. Time bounded access is far easier to approve.
It should. A full dedupe run against a refreshed sandbox tells you the match rate and the false positive rate before anything touches production.
Accounts, contacts, leads, opportunities, activities. Each has different merge behaviour and different blast radius. Opportunities and activities are where damage becomes hard to reverse.
One named person, with the sandbox results in front of them. Not a standing approval granted at kickoff.
If a merge is questioned in three months, the log is the only thing that answers it.
Which records were combined, which survived, which fields were taken from where, and the rule that triggered it. Stored outside the CRM, because the losing record is gone from inside it.
Deterministic match on email is different from a probabilistic match on name and company. Recording which applies lets you reverse one class without touching the other.
Automated rule, or a human review decision. Mixed projects need both distinguished.
Keep it at least as long as your sales cycle, so a disputed account can be traced back. Agree the period with whoever owns data retention.
The question security will ask, and the one most projects answer vaguely.
Be specific. Most CRMs do not unmerge natively, so reversal means recreating the losing record from the log and reparenting activity. Know whether your platform supports it before you commit to a method.
Different problem. Usually a restore from a point in time backup, which means knowing your backup granularity and your restore time before the first run.
Say it plainly. Reparented activity history and deleted custom field values often cannot be fully recovered. Naming this is what makes the rest of the plan credible.
How long after a merge can it be reversed cheaply. After that window, reversal becomes a data recovery exercise. State the date.
Duplicates return. The question is whether anybody is watching when they do.
A named person in RevOps, not the consultant and not the CRM admin by default. Rules need tuning as the business changes.
Usually an intake control: validation at point of entry, or a check against the matching rule before a record is created. Cleaning without this buys about two quarters.
Low confidence matches should queue for human review rather than auto merging. Agree who clears that queue and how often, or it becomes a backlog nobody owns.
Put a date on it. Quarterly is typical. Rules written once and never revisited drift out of step with how the business sells.
A regional property and casualty insurer unified policy records across four systems. The scale is what makes the logging and rollback questions non negotiable rather than bureaucratic.
Will you run the full matching rule against a sandbox first and show us the false positive rate?
What exactly is preserved for each merge, and where is it stored?
Walk me through reversing one merge, and then reversing a batch of ten thousand.
What intake control stops the duplicates returning, and who owns it after you leave?
Rarely in full, and that is the point of settling this first. Most platforms do not offer a native unmerge, so reversal means recreating the losing record from a log you kept and reparenting its activity. Anything that depended on the old record identity, such as reporting history or external integrations keyed to it, may not come back cleanly.
Because it needs broad write access to the system holding your customer data, and because a bad rule at scale is a data loss event rather than an inconvenience. Time bounded named access, a sandbox proof, and a written rollback plan answer most of what a reviewer will ask.
An intake control, which is the step most cleanup projects skip. Validation at point of entry, or a check against the matching rule before a record is created. Without it you are buying roughly two quarters of clean data and will be back where you started.
No. Queue them for human review and agree who clears the queue before the project starts. Auto merging on low confidence is how a real account gets absorbed into the wrong parent, and that is the failure that loses trust in the whole programme.
A named person in RevOps who understands how the business actually sells. Not the CRM administrator by default and not the consultant. Rules need tuning as segments and naming conventions change, and an unowned rule set degrades quietly.