CRM Data Cleanup: Review Duplicates and Protect Sales History

Start CRM data cleanup with a small group of records and a specific problem: duplicate contacts, incorrect details, missing owners or unreliable reporting. Export the affected information and relationships, inspect a few real examples, then choose the smallest supported correction. Check how the exact operation can be recovered before approving a merge or deletion.

The aim is a record your team can trust. A smaller database is not necessarily a better one. Two people can share an email address, and one customer can have several legitimate opportunities. Cleaning those distinctions away can make the CRM look tidier while making the next customer conversation harder.

Use the CRM data cleanup companion pack for review templates and fictional examples. Begin with the decision worksheet described below. The technical exercises are optional, and none of the example approvals authorizes a change in your CRM.

Look at the customer conversation behind the duplicate

Imagine an account manager preparing to call Léa Martin at a fictional office-services customer. Searching the CRM returns two contacts with the same verified customer identity. One contains last month’s discussion; the other is linked to a current proposal. The manager cannot tell which is current without opening both.

That is a useful cleanup candidate. The eventual record should let a colleague understand the relationship without losing the separate proposals or their history.

Now consider two contacts named Alex Chen. They work at related companies but have different verified customer identities. Combining them would put one person’s conversations and opportunities under another person’s name. Their similarity is a reason to inspect them, not permission to merge.

A third pair, Robin and Morgan, share a billing mailbox. Both are legitimate contacts with different responsibilities. One approves service changes and the other handles invoices. Replacing them with a single “complete” contact would remove useful context.

These are hypothetical examples used throughout the guide. They demonstrate the first cleanup decision: are you looking at two versions of one entity, or two legitimate entities that happen to share information?

Software can find similarities quickly. The business still needs a policy for interpreting them. A duplicate suggestion should be treated as a question until the evidence supports an answer.

Identify the problem before choosing the operation

“Dirty data” is a broad label. It can describe several tasks with different risks. Separate them before applying a bulk action.

Formatting work changes how a value is represented. Removing accidental spaces around an email address or standardizing an approved province code may improve consistency. It should not change the identity or meaning of the record.

Correction replaces an incorrect value with a supported one. A customer confirms a new phone number, or a salesperson discovers that an opportunity was assigned to the wrong account. This needs evidence about the correct value, not merely a formatting rule.

Deduplication decides whether records describe the same person, organization or buying decision. It can affect linked history and external references, so it deserves more scrutiny than trimming spaces.

Retention review decides whether information still has a valid purpose and how it should be archived or removed under the business’s approved policy. Old information is not automatically worthless, and keeping everything indefinitely is not a retention policy.

Let the symptom guide the first sample

If sales keeps contacting the wrong person, inspect contact details, roles and recent confirmation evidence. If two employees keep replying to the same enquiry, inspect how people and requests are created across channels. If a report appears inflated, inspect the underlying opportunities before assuming the contact list is the cause.

If marketing suppression is unreliable, prioritize the permission records and sending-system connections. A mass name-formatting exercise will not solve that risk. If records are ownerless, identify the departed users or import process involved and repair responsibility.

Choose a bounded starting group, such as contacts created by one import or enquiries from one form. That gives you a reasonable chance of discovering the cause and checking the result. A small successful batch is also easier to explain than a database-wide operation whose effects are mixed together.

Write down the outcome you need. “A colleague can find the current phone number and all relevant open work” is useful. “Reduce contacts by 20%” rewards removal whether or not it improves the business record.

Make a usable copy before changing anything

Export the selected records and identify what the export includes. A contact CSV may hold names and fields while omitting notes, emails, attachments, subscription history or links to other objects. That is a copy of part of the data, not evidence that the whole relationship can be restored.

For the Léa example, preserve both contact IDs, their fields, the notes attached to each, their opportunity links and any relevant communication choices. Record which system each ID comes from. Customer 104 in a billing platform is unrelated to customer 104 in an old CRM unless you have a verified mapping.

Keep an unmodified source copy and a separate working copy. Record when the extract was taken and which records it covers. Preserve IDs as text so spreadsheet software does not remove leading zeros or change long numbers.

Store the files where authorized reviewers can access them, with protection appropriate to the information. Avoid distributing a full contact export to everyone involved when a restricted sample or record reference would serve the decision.

Check who can obtain the missing pieces. An export performed by a limited user may omit records or activities they cannot see. A file that looks complete may simply reflect that person’s permissions. Ask the system owner to confirm the scope rather than infer it from the column names.

Also identify external systems that use the CRM’s record IDs. Invoices, support tickets and integrations may continue pointing to an old contact after the CRM view changes. Those references belong in the plan before records are consolidated.

Account for work that continues during cleanup

Customers do not stop calling while you prepare a batch. Sales may add a task, a customer may change an address or someone may unsubscribe after the export.

Choose how those later changes will be captured. A short, approved pause on the affected updates may work for a small batch. Another business may need a final change extract or a supported comparison immediately before execution. Keep essential intake available through a clear continuity process.

The important rule is that approval relates to the reviewed information. If the record has changed materially since review, inspect the current state again. Yesterday’s decision should not overwrite a new preference or opportunity simply because the IDs are unchanged.

Deal with outdated and incomplete records deliberately

Some of the most disruptive data problems involve one record that has become misleading. A contact has changed employer, a sales owner has left or an old proposal remains marked active. Deduplication alone will not repair those situations.

When a contact moves to another company, preserve the history of the earlier relationship. A conversation about a former employer’s proposal should not automatically become part of the new employer’s account. Decide which organization associations are current and which remain historical, using the model your CRM supports. Verify the person’s new role through an appropriate business source before changing it.

A bounced email needs a contactability decision. Inspect the actual sending result and establish whether the address is invalid, temporarily unavailable or affected by another problem. Do not guess a replacement address and treat it as verified. Keep any communication restriction and the reason visible while an authorized person checks the contact details.

Ownerless records need different treatment. A departed employee may have left behind active enquiries and promised actions. Find that work and arrange an accepted handoff. Updating a user name in bulk without checking open commitments can make the database appear assigned while the customer remains unattended.

For old opportunities, ask whether the buying decision is genuinely active, paused, lost or duplicated. An expected close date in the past is a prompt to review, not proof that the customer rejected the offer. The person responsible for the relationship should establish the current position. Preserve the reason and date of any correction so historical reports can be understood.

Incomplete fields should be evaluated by use. A missing mobile number may be acceptable when the customer prefers email. A missing service address may prevent an assessment. Work first on the gaps that stop the next business action, and identify who can obtain the information appropriately.

Avoid filling blanks with convenient defaults merely to improve a completeness score. An unknown budget should remain unknown until supported. A placeholder company size or guessed job title can later influence routing, scoring and reporting as though it were a fact. It is better to show an unresolved question than create false certainty.

If enrichment software is involved, distinguish a suggested value from a verified customer statement. Check the source, age, permitted use and process for resolving conflicts. New data from a tool should not automatically override a customer’s more relevant correction or preference.

Finish this part of the review with a disposition that explains the next step: corrected from evidence, awaiting confirmation, assigned for follow-up, legitimately blank or referred for retention review. These outcomes give the team a usable record without pretending that every field can or should be completed immediately.

Review candidates with five practical questions

Use a short worksheet for the first pass. You can add technical detail later for cases that need it.

1. What suggests these records describe the same entity?
2. What evidence suggests they are different?
3. Which values and relationships should remain?
4. What could this operation affect outside the visible record?
5. What can we recover if the decision is wrong?

For Léa, the shared verified customer identity supports consolidation. The two distinct proposals should remain separate and linked to the continuing contact. The system owner must check notes, permission history, connected IDs and the actual merge behaviour before execution.

For the two Alex Chens, distinct verified identities support keeping both. The worksheet should say why, so the same suggestion does not return without context next week.

For Robin and Morgan, the shared billing email is a relationship feature. It does not establish that they are one person. Preserve their roles and give the shared address an appropriate meaning in the data model.

Allow the answer “needs review.” A cleanup process that forces every candidate into merge or delete will mishandle uncertainty. Give unresolved cases a reason and a responsible person so they remain deliberate work rather than an abandoned queue.

Review groups, not just isolated pairs

Suppose record A shares an email with B, and B shares a phone number with C. That does not prove A and C are the same person. B may contain mixed information from an earlier error, or the contact details may be shared.

Inspect the whole candidate group before consolidating part of it. After any approved change, refresh the remaining candidates. The evidence may have changed, and an old pairwise recommendation may no longer describe the current records.

Save confirmed non-duplicate decisions with a reason and a sensible review trigger. Shared premises, family contact details and parent-subsidiary relationships are common reasons for similarities that should remain. Making those decisions easy to find prevents repeated review from eventually turning into an accidental merge.

Clean formatting without changing meaning

Perform transformations in the working copy first. Keep the original value beside the proposed value and explain the rule. A comparison key used to find candidates does not automatically belong in the customer-facing field.

For an email address, removing surrounding whitespace is different from removing punctuation or plus tags. Provider-specific addressing conventions should not be applied to every address. A rule that assumes dots or text after a plus sign are always irrelevant can combine addresses incorrectly.

For phone numbers, preserve extensions and establish the country context before reformatting. A shared switchboard can support several distinct contacts. Do not infer personal identity merely because the main number matches. Keep numbers as text where formatting must survive.

Names need particular care. Preserve accents, apostrophes and the person’s supported preferred form. A confirmed preference for Rob does not justify converting every Robert in the database. Automated capitalization can also damage names and organization brands.

For dates, decide whether the field represents a calendar date or a precise event. A service date should not shift because someone views it in another time zone. An enquiry timestamp needs enough context to identify when it actually arrived. Ambiguous legacy entries need review rather than a silent guess.

Keep missing values distinct from meaningful values. Unknown revenue is not zero revenue. An empty marketing field is not permission. A blank service location may mean the team still needs to ask; “not applicable” may be appropriate only for particular services.

Test a transformation on difficult examples, then apply it twice in the working copy. A stable formatting rule should not keep changing its own output. Include accented names, commas, long notes and leading-zero IDs in the test set.

If a transformation affects a large number of records unexpectedly, stop and inspect the rule. A broad change can be technically consistent while operating on the wrong column or misunderstanding the source format.

Decide what remains, field by field

Choosing the continuing record and choosing its values are separate decisions. The record with the most fields filled in may contain guesses. The newest record may contain a typo. The oldest may have valuable history and obsolete contact details.

For each important field, identify the source you trust and why. A recently confirmed customer phone number can be more reliable than a newer import. Finance may control the billing contact while sales maintains the buying contact. An account manager’s ownership should follow the approved assignment policy.

Record the evidence time where available. A record’s last-modified date may reflect a task change rather than confirmation of the address. If the merge gives the field a new technical timestamp, keep the original business evidence separately where needed.

For Léa, the review might preserve her supported preferred name, a verified phone number from one record and an original acquisition source from the other. Both distinct opportunity links remain. The continuing record is assembled from justified decisions rather than declared correct wholesale.

Retain alternative contact details only when the business has a reason and a permitted way to use them. Label an old work email as historical if appropriate; do not leave several unlabelled addresses for the next employee to guess between.

Avoid rewriting history to make records consistent. A lost opportunity stays lost unless a separate correction is approved. A previous owner remains part of the history even if current responsibility changes. A note explaining a disagreement can supplement the record without replacing what actually happened.

The technical term for these choices is survivorship: what survives a consolidation. The practical test is whether another employee can explain why the remaining value is the one the team should trust.

Preserve buying decisions while combining contacts

One person can be involved in several purchases. Consolidating their contact records does not mean their opportunities are duplicates.

In the fictional Léa example, one contact is linked to a CAD 4,000 opportunity and the other to a separate CAD 5,000 opportunity. Combining the contact relationship should leave both opportunities and their combined CAD 9,000 value intact. Cleanup has not created revenue or established that either sale will close.

Check each opportunity’s identity, scope, stage, currency and relevant contacts. Two proposals with similar titles may represent a renewal, a new location or an alternative scope. Compare the buying decision, not just the text label.

Organizations require the same care. A parent company and subsidiary may share an address while remaining separate contracting entities. A customer may have several branches with different service responsibilities. Decide what your account records represent before treating a shared address as duplication.

Preserve the type of relationship as well as the link. Being the billing contact for an account differs from being the decision-maker for a specific proposal. A total of two associations does not prove that the right two associations remain.

This is one reason to sample real work after cleanup. Ask the salesperson to find the current proposal and the person who approves it. Ask operations to find the service contact. The answer should be clearer than it was before the change.

Keep permission conflicts out of automatic merges

If one record says subscribed and another records an opt-out, preserve the underlying events and hold the affected marketing use while the conflict is reviewed. A new import timestamp should not erase an older unsubscribe event whose business meaning still applies.

Check what each event covered: which person or address, channel, purpose and date. A preference for one newsletter may differ from a request to stop all marketing. A single yes/no field may not explain that history.

The CRTC’s CASL questions and answers describe the general requirements for commercial electronic messages and the importance of retaining evidence supporting consent. Your responsible adviser or compliance owner should determine how those requirements and any exceptions apply. A cleanup operation cannot create permission that the underlying evidence does not support.

The operational hold recommended here is a precaution for the disputed use, not a legal conclusion about every communication. A service message, an active sales conversation and a promotional campaign may require different assessment. Keep the uncertainty visible and assign the review to someone with the appropriate responsibility.

Check the sending system, too. Preserving an opt-out inside the CRM is insufficient if an email platform still treats the address as marketable. Review the flow in both directions so an older list import cannot reintroduce the disputed status.

Privacy and retention decisions are similarly contextual. The Office of the Privacy Commissioner’s PIPEDA principles include accuracy, retention limits and safeguards where that law applies. Confirm the relevant federal, provincial and sector requirements for the organization. Do not invent a universal rule that every contact older than a particular date should be deleted.

Check the exact operation and its recovery limits

Merging, updating through an import, deleting and restoring are different operations. A vendor’s undo feature for one does not establish that another can be reversed.

HubSpot’s current merge documentation states that records cannot be unmerged. It describes object-specific behaviour and an account beta affecting whether the primary record ID is preserved. Check the actual account and operation before relying on an old-to-new ID mapping. Creating a replacement record later is not the same as undoing the merge.

Pipedrive’s Merge Duplicates documentation also says merged items cannot be unmerged. Its separate spreadsheet-import guidance describes reverting an import from history within 48 hours. That import provision is not an undo promise for a manual duplicate merge.

Use the current official documentation for your product and account before execution, particularly where a beta or object type changes behaviour.

Ask the administrator five concrete questions: what remains, what disappears, which relationships move, what automation may run and what supported recovery exists? If any answer is uncertain for a consequential record, hold that action until the uncertainty is resolved.

Review the operation preview against your plan. Check both field values and linked objects. Do not assume that a contact merge also consolidates every external document library, invoice reference or service record. Each connected resource needs its own check.

Classify recovery honestly

Some field corrections can be reversed by restoring the prior value, provided no later valid update is overwritten. Other actions may allow a supported vendor restoration within specific conditions. An irreversible merge may require reconstruction, with new IDs and incomplete historical behaviour.

Label the planned recovery accordingly: supported reversal, reconstruction with known limits, or unverified. If you cannot explain how the important history would be recovered, do not let a reassuring backup filename substitute for the answer.

A recovery rehearsal should verify the parts that matter to the business: record identity, relationships, relevant activity, access and connected references. A restored name and email alone do not establish that the customer relationship is restored.

Work through a mixed sample before a larger batch

A useful sample includes obvious candidates and cases that should stay separate. The companion’s fictional Cedar Lantern Office Services dataset contains eight deliberately chosen situations. Their proportions are teaching choices, not estimated duplicate rates.

Léa’s two records have the same verified identity and distinct legitimate opportunities. The proposed consolidation preserves the activities and both buying decisions. It is a candidate for a reviewed operation after technical readiness is established.

The two Alex Chens have different verified identities. Keep them separate despite the name match. Robin and Morgan share a billing email but are different people with different roles. Keep both contacts and preserve that relationship information.

Rob and Robert Singh have a specific fictional confirmation establishing that the records refer to the same person. The preferred name can be retained under that evidence. Another Rob/Robert pair without the confirmation remains unresolved; one example does not validate a universal nickname rule.

A fifth pair has conflicting marketing-permission history. Hold the affected use and review the events before proceeding. A sixth case involves parent and subsidiary accounts at the same address; preserve their separate identities.

A seventh pair has matching name and phone information but conflicting source identities. That conflict warrants review rather than a confidence score that hides it. The eighth pair appears to describe one person, but a linked-history export is missing. The identity conclusion may be reasonable while the operation remains unready.

That last distinction is important. “These are duplicates” and “We can safely perform this merge now” are different decisions. Missing recovery evidence does not change who the person is; it changes whether you should execute the action.

Have another reviewer explain the sample outcomes from the evidence where practical. Disagreement can reveal an unclear identity definition or an assumption that would affect the larger batch. Resolve it before scaling the work.

Run the approved batch in a controlled way

Keep proposed changes separate from completed changes. For each candidate, identify the records, intended result, important field choices, relationship changes, reviewer and recovery method. A small batch can use a modest worksheet; high-risk work may need more formal controls.

Choose a time when the people responsible for the records and system are available. Tell affected staff which records are involved and how to continue handling customers. Avoid surprising a salesperson with a disappearing record during an active call.

Immediately before execution, compare the current records with the reviewed state. A new opportunity, permission change or reassignment may alter the decision. Refresh the review for that candidate rather than forcing it through because the batch is scheduled.

Perform only the approved operations. Record the actual result and resulting ID. If an operation fails or times out, inspect the current state before retrying. A timeout does not reliably establish that no change happened.

Pause when the result differs materially from the plan. Missing activity, an unexpected owner change or a restored marketing status deserves investigation before more records are affected. Keep the execution record so the administrator can identify the smallest relevant scope.

Avoid testing customer-facing automation on real customers. Rehearse with invented records and approved destinations, and agree how live downstream actions will be controlled during the actual batch. Necessary service communications still need a continuity plan.

After a small batch behaves as expected, expand only as far as the review and recovery capacity support. Speed of processing is less important than being able to explain and correct the result.

Check the result at the level where mistakes matter

Record counts are a useful first check. They are not the final check. A missing contact and an accidental extra contact can cancel out in the total.

In the companion’s static example, 16 starting records become 14 after two approved simulated consolidations. No new records or separately approved removals occur. That arithmetic is simple: 16 minus 2 equals 14. Each original record still needs a clear destination or a reason it remains unchanged.

Inspect the held and non-duplicate records as well. Alex, Robin and Morgan should not have been changed merely because they appeared in the review sample. A successful approved merge does not excuse an unrelated alteration elsewhere in the batch.

Compare linked history by identity and meaning. The right note must remain with the right person; finding its ID somewhere in the export is insufficient. Check a few activity contents, attachments and access permissions, especially where the system represents associations differently after a merge.

Reconcile opportunities using the same currency, reporting period and filters as the baseline. Contact counts may fall while opportunity value remains unchanged. If a source or owner change alters a report, explain the effect rather than quietly replacing the previous number.

Check connected systems after their normal processing interval. Confirm that updates reach the continuing record and that obsolete IDs have the approved mapping. Verify disputed or suppressed marketing states in the system that actually sends messages.

Finally, ask the people doing the work to use the cleaned records. Can they find the current contact details, next action and open proposal? The cleanup should improve that task without concealing the history they need.

If the cleanup reveals a mistake

Stop further work on the affected group and preserve both the current state and the original review evidence. Identify what happened, which records are affected and whether any downstream communication or access needs to be contained through the approved process.

For a field correction, compare the current value with the value your batch wrote before restoring the old one. A customer may have supplied a legitimate update after the cleanup. Reversing blindly can create a second error.

For an incorrect merge, establish which histories belonged to each person and which activities were added afterwards. Where the vendor cannot unmerge, reconstruction requires a specific plan. A replacement record may have a new ID, and some audit or integration behaviour may not be recoverable.

Treat later changes separately. Restoring yesterday’s snapshot without accounting for today’s tasks, opt-outs and customer messages can erase valid work. Capture the later activity and decide how it will be reconciled under the supported recovery method.

Have the responsible business owner understand any remaining limitation. “The contact exists again” is not enough if the linked proposal or subscription history is still wrong. Close the incident when the relevant relationships, permissions and external references have been checked.

Add a regression example for the cause. If the error came from a shared mailbox, ensure that a shared-mailbox case must remain separate. If a stale import overwrote a restriction, test that sequence after the rule is repaired. Keep the reason for the change with the updated policy.

The goal is to make the next decision safer, not to claim that recovery can always restore every detail. The best time to discover a recovery limit is before the original operation.

Stop the same problems from returning

Trace recurring issues to their source. A form may create a person for every submission. An import may omit stable record IDs. A connector may retry by creating a new record. Staff may create duplicates because they cannot find the existing contact quickly.

Confirm the actual cause before changing the system. Similar duplicates can arise through different paths. Fixing the form will not resolve a monthly import that recreates the same people.

Separate person creation from enquiry creation. A returning customer can make a new request while retaining one contact identity. Likewise, another buying decision can be a new opportunity without duplicating the customer. The CRM implementation plan explains that relationship model in the wider sales journey.

Make required fields timely and understandable. If staff must enter an amount before they know the scope, they may enter zero or a guess. If a loss reason has no suitable option, they may choose whichever value lets them save. These are design problems, not simply failures to keep data clean.

Review permissions and search access. An employee who cannot see the existing record may reasonably believe it does not exist. Resolve the legitimate access or intake process rather than telling everyone to search harder.

Keep a small set of quality checks tied to business work: missing owners, unresolved identity conflicts, broken links, unsupported marketing states and repeated sources of duplication. Review them at a cadence the team can maintain. A monthly cleanup is not universally right; volume and consequence should guide the frequency.

Maintain confirmed non-duplicate explanations under the approved retention policy. A well-documented decision that two contacts share a mailbox can prevent the same costly debate from recurring every time a tool scans the database.

Use the companion as a review aid

The download contains blank review templates, fictional examples, a field dictionary, recovery prompts and a self-contained technical exercise. Start with the questions needed for your batch. The larger registers are available when the scope requires them.

Keep the fictional records separate from your working data. Their names, approvals, IDs and amounts are teaching material. The exercise does not authenticate reviewers, obtain business permission or connect to your CRM.

Its preserved report covers 104 synthetic checks around the supplied model, including false matches, permission holds, missing history, field preservation and a narrow recovery example. Passing those checks demonstrates the example’s behaviour under those conditions. It does not prove that a vendor can reverse your merge or that your actual account is ready.

The executable example handles two explicitly defined fictional consolidations. Editing a policy field does not turn it into a general-purpose merge engine. The accompanying live-validation worksheet begins with tests unperformed; fill it with actual results only after authorized account testing.

You can finish a useful cleanup decision without running the code. Establish the problem, inspect the identity evidence, preserve the relevant relationships and verify the exact operation. If a critical answer remains uncertain, keep that candidate on hold and continue with the independently safe work.

A clean CRM should make the next customer interaction easier to understand. Judge the project by that outcome, with the history and limitations still visible, rather than by how many rows disappeared.

Frequently asked questions

What are the main methods of CRM data cleaning?

CRM cleanup usually involves four different jobs: formatting, correction, deduplication and retention review. Formatting changes how a value looks, such as trimming spaces around an email address, while correction replaces a wrong value with one that has supporting evidence. Deduplication decides whether two records describe the same person or buying decision, and retention review decides whether information still has a valid purpose. Each carries a different risk, so separate them before any bulk action.

How do you clean a messy CRM database without losing sales history?

Pick a small group of records and one specific problem, such as duplicate contacts from one import. Export the affected records along with their notes, opportunity links and permission history, and keep an untouched copy beside a working copy. Inspect a few real examples, choose the smallest supported correction and check how that exact operation can be reversed before approving a merge or deletion.

Can an AI tool clean up CRM data on its own?

Software can flag similar records quickly, but a duplicate suggestion is a question until evidence answers it. Two contacts with the same name may be different people at related companies, and two people can legitimately share a billing mailbox. Your business still needs a written policy for interpreting matches, and a person should approve merges that affect history or permissions.

Do I need separate software for CRM data cleaning?

Often the CRM's own merge and export features are enough for a bounded batch, as long as you know exactly what each operation does. Check what a merge keeps, what it discards and whether it can be undone before you approve it. Also confirm what an export actually contains, because a contact CSV may leave out notes, emails, attachments and subscription history.

What is CRM data, and why does cleaning it matter?

CRM data is the record of your customer relationships: contacts, organizations, owners, opportunities, notes, emails and communication choices such as unsubscribes. When it drifts, sales may call the wrong person, two employees may answer the same enquiry or a report may look inflated. The goal of cleanup is a record your team can trust, which is not always a smaller database.

What does a CRM data cleanup example look like in practice?

The post uses three fictional pairs. Two contacts for the same verified customer, one holding last month's discussion and one tied to a current proposal, are a fair candidate for consolidation. Two people with the same name but different verified identities stay apart, and so do two colleagues who share a billing mailbox but hold different responsibilities.

How should ownerless records be handled during a CRM database cleanup?

Find the work a departed employee left behind, such as active enquiries and promised follow-ups, and arrange a handoff that someone accepts. Reassigning the user name in bulk without checking open commitments makes the database look assigned while the customer waits. Treat old proposals the same way and ask whether each buying decision is still active, paused or lost.

How do you keep CRM data clean after the first cleanup?

Trace each problem back to where records are created, such as one import, one web form or a channel that makes a new person for every enquiry. Fixing that entry point stops the same duplicates from returning. Keep permission conflicts out of automatic merges, and measure success by whether a colleague can find the current details and all open work, not by how many contacts were removed.