Use AI to prepare duplicate CRM records for review, choose which values survive, check connected records and prevent the same duplicates from returning.
Imagine two contacts in your CRM called Alex Rivera. One has a recent phone number and an open opportunity. The other has years of emails, a support case and an older company address. An assistant flags them as a likely duplicate. Someone still needs to establish whether they are the same person and what should happen to everything attached to those records.
That decision is where an AI cleanup project earns its value. A shorter contact list is easy to produce. A contact list that sales, support and finance can trust takes more care.
AI can help compare records, explain possible matches and prepare a review. Give it that work first, with the evidence visible beside its suggestion. Keep the merge behind an explicit decision until your team has tested both the matching rules and the CRM's actual behavior.
Our CRM data hygiene overview covers the wider cleanup effort. Here we will follow one duplicate pair from suggestion to verification, then look at how to stop the same problem returning.
Choose the kind of record you are matching
Start with one object, such as contacts. Decide what a contact represents in your business. Is it an individual person, a person's relationship with an employer, or an account used by several colleagues? The answer changes how you treat a familiar name with a new company.
List the identifiers you can rely on and the systems that issued them. A verified customer reference from the application may carry different evidence from a name entered on a marketing form. Two records can share a company address because the people work in the same office.
Keep the original values available when you normalize them for comparison. Removing punctuation from phone numbers may help find candidates, but country codes, extensions and shared switchboards still need interpretation. Turning a missing value into an empty match should never make two unrelated records look more certain.
Write down what would stop a proposed merge. Conflicting verified customer IDs, incompatible account relationships or unclear ownership should send the pair to an exception queue. Resolve the uncertainty before the records are combined.
Ask AI for a comparison you can check
Prepare a small comparison with the two record IDs, relevant values, source systems and the dates those values were checked. Give the assistant only the information needed for the task, within the access already approved for that workflow.
The useful output is specific. It should say which evidence supports the match, which fields disagree and what a reviewer still needs to establish. “These are probably the same customer” does little to help someone decide.
A confidence score can help order a queue, but should not replace the underlying evidence. If the assistant reports a high score because names and company domains match, the reviewer should be able to see that reason and judge whether it is sufficient.
Separate a proposed identity match from proposed field changes. You may confirm that two records describe the same person while rejecting the suggested job title or owner. A review interface that forces one decision for the whole record makes those cases harder to handle.
Give reviewers a clear next action
This is an original decision framework for a contact cleanup pilot. It is not a description of automatic behavior in Zoho or HubSpot, and it does not assign universal matching probabilities.
| Candidate pair | Evidence to inspect | Review decision | Check before any merge |
|---|---|---|---|
| Same verified customer ID, different display names | Source identity and the reason for the name difference | Confirm the identity and propose the retained name | The identifier genuinely belongs to one person |
| Same name and company domain, no reliable shared identifier | Contact details, account context and record sources | Keep separate while the identity is unresolved | Similarity has not been treated as proof |
| Same email, conflicting verified customer IDs | Whether the address is shared, reused or incorrectly mapped | Hold the pair for the integration owner | The conflict is explained and recorded |
| Same person, different employers | Employment dates and the accounts linked to each record | Decide how the CRM should represent the relationship | Deals and service history remain with the intended account |
| Duplicate created by an import, with history on both records | Import references, activities and connected records | Choose a master and review each conflicting field | Required relationships will survive the operation |
| Matching identity, conflicting communication preferences or ownership | The authoritative source and the responsible business owner | Route the disputed values for a separate decision | A merge will not silently replace an unresolved preference |
Record why a pair was accepted or rejected. A rejected pair is useful evidence for the next matching pass. Otherwise, the same two legitimate contacts can return to the top of the queue every week.
Keep the decision close to the records it concerns. A reviewer should be able to open both CRM entries, inspect the comparison and return to the task without searching for an exported spreadsheet.
Decide which values should survive
Choosing the master record does not settle every field. One record may have the correct owner while another has the verified phone number. Define a rule for each important field and identify where a person must decide.
The newest timestamp is not always the best authority. An import yesterday may have copied an old spreadsheet, while a support agent verified the current phone number last week. Keep the source and verification context beside the proposed value.
Show the reviewer a before-and-after view. Include the surviving record ID, values that will change and conflicts left unresolved. If a connected application stores the other record's ID, put that relationship in the review too.
Treat account ownership, lifecycle stage and communication preferences deliberately. A model should not infer those decisions merely because two records appear to describe the same person. Ask the responsible owner how each conflict should be handled and document the rule.
Check what your CRM actually does with a merge
HubSpot's merge documentation describes combining two records of the same object, including activities, associations and most property values. It also states that records cannot be unmerged. That makes the preview and the decision about retained values particularly important.
In Zoho CRM's V8 Merge Records API, a merge can combine up to three records into a retained master and delete the child records. The request can specify child field values to keep, with other values retained from the master. Check the supported object and field behavior for your own operation before building the review around it.
Try the operation in an appropriate test environment using representative records. Include activities, attachments, open work and the relationships your integrations depend on. Confirm what the person handling the next sales or support request will see afterwards.
Keep a pre-change record of the affected values and relationships, but do not describe an export as a complete undo plan without testing recovery. Recreating contact fields may leave further work to restore context in connected systems. Name the person who will handle that repair if a decision turns out to be wrong.
Re-read the pair when approval arrives
A comparison prepared on Monday may be out of date by Thursday. A sales representative could have changed the owner, or a support agent could have added information that settles the identity question.
Before executing an approved merge, retrieve the records again and compare the fields relevant to the decision. If they changed, refresh the preview and ask for review where needed. Approval of an earlier state should not silently authorize a materially different one.
Give the operation a durable reference in your integration. Keep the source IDs, chosen master, approved changes, reviewer and execution result together. This helps an operator distinguish a new request from a retry of work already attempted.
Handle uncertain responses carefully. Zoho documents situations where the merge runs asynchronously and returns a job ID. A submitted job needs its resulting status checked. If a connection fails around a write, inspect the CRM before sending another operation against records that may already have been merged.
Verify the relationships after the request succeeds
Open the surviving record and check the values the reviewer selected. Then inspect the connected work. Can the assigned representative still find the opportunity? Does the support team see the relevant case and the expected account relationship?
Check any integration that stored a deleted record ID. A successful operation inside the CRM does not establish that every connected application has adopted the surviving reference. Keep a mapping where your integration needs one, and verify the affected downstream task.
Review workflow side effects in your test setup. A field update or changed association may affect routing, reporting or a customer-facing process, depending on your configuration. Establish that behavior before running a large batch.
Mark a pair complete only after the agreed checks pass. Keep submitted, processing, verified and needs-repair as separate states so an accepted API request does not make unfinished work disappear from the queue.
Measure the review effort honestly
For an illustrative batch of 100 candidate pairs, suppose the current manual process takes three minutes each. That is 300 minutes, or five hours.
Now assume an AI-prepared comparison brings the initial review to one minute per pair, taking 100 minutes. Twenty-five complex pairs still need another four minutes each, adding 100 minutes. Reserve 30 minutes for the agreed quality checks. The total is 230 minutes, saving 70 minutes against the assumed baseline.
These figures are a planning example, not a product benchmark or a client result. Measure the actual review, exception and repair time in your pilot. A mistaken merge that takes hours to investigate can outweigh several batches of small time savings.
Track rejected suggestions and confirmed errors alongside throughput. If reviewers reject most suggestions because the same shared email pattern keeps appearing, improve candidate selection before asking the team to process a larger queue.
Fix the process that created the duplicates
Look at where accepted duplicate pairs came from. A website form, a repeated file import or an integration that always inserts a new contact may need attention. Cleaning the records without changing that entry point gives the team recurring work.
Zoho's Upsert API documentation explains how duplicate-check fields determine whether a request updates an existing record or inserts a new one. It also allows a specified check-field order. Test those choices against your identity rules; an unsuitable matching field can update the wrong record.
For each incoming source, decide which identifier it supplies, what it can update and how conflicting values are handled. Keep those decisions aligned with the rules used in your cleanup review, so one integration does not immediately recreate a conflict another process resolved.
Start with a small owned queue, review the difficult examples and keep evidence of the resulting records. Expand when the team can explain both a correct merge and a rejected suggestion, and can carry out the repair process if needed.
Our Zoho CRM services can help configure the record rules, ownership and integrations involved. Our AI agent development team can build the comparison and approval workflow around them. Contact Emerging Stacks with one recurring duplicate pattern and the systems that create it.
Ready to work with us?
Get in Touch


