Review CRM Duplicate Contacts Before Merging: A Form and Import Checklist

A duplicate-contact alert is a request to investigate, not an instruction to merge. Two records may describe the same person under different email addresses. They may also describe colleagues with similar names, or separate people who have used a shared inbox. A useful CRM duplicate contacts checklist starts by finding where the records came from, then compares what each record holds before anyone changes it.

Keep the review reversible until the decision is clear. Record the candidate pair, the evidence for or against a match, and the data that must survive. Then decide whether to merge, correct a field, reject the suggestion or leave the pair open. In HubSpot, for example, a reviewer can compare and reject suggested pairs, while a completed merge cannot be undone. HubSpot’s duplicate-record guidance makes that distinction explicit.

Map every route into the contact list

Start with the entry points that create or update contacts: website forms, event registrations, manual entry, spreadsheet imports and connected systems. For each route, identify the field used to recognize an existing person, the fields it can overwrite, and the person responsible for checking exceptions. A list of duplicate pairs is easier to resolve when it includes the creation source and date for both records.

Separate two kinds of candidate:

• Exact-email match: the same address appears on more than one record or incoming row. Check whether an integration, import or earlier migration bypassed the expected matching process. An identical address is strong evidence to investigate, but inspect the records before consolidating them.
• Likely same person, different addresses: a work address and a personal address, a changed employer, or a corrected spelling may explain the difference. Name, phone, company and activity can help build a case, but none establishes identity by itself.

HubSpot documents why the distinction matters. It uses the Email property to match contacts automatically during ordinary creation, form submission and import. For imports, a Record ID can identify an existing record even when an email address is absent or changing; without an email or another unique identifier, each imported row can become a new contact. Those are documented HubSpot matching rules, not rules to assume for every CRM.

Compare the full records, not just their names

Open both contact records and compare their identifiers, creation sources and recent activity. Look for evidence that points to one person: a documented address change, the same direct phone number with consistent context, or notes that explicitly connect the two records. Also look for contradictions. Different job roles, separate conversations occurring at the same time, or distinct associated companies may indicate two people.

Before choosing a primary record, check what each one contains:

• Owner and next action: who is responsible for each record, and whether either has an active follow-up. Resolve conflicting ownership with the people involved.
• Consent and communication preferences: inspect the recorded choice, its source and any opt-out history. Do not infer permission from a second record that has a different status or no evidence.
• Notes and activities: read enough history to understand who each conversation concerns. Flag private or context-specific notes that need careful handling.
• Lifecycle stage: record both values and why they differ. A later stage may reflect a real relationship, an automated form setting or an old import.
• Associations: inspect linked companies, deals, tickets and other records. Confirm that each relationship belongs to the proposed surviving contact.

A merge can change more than the visible name and email. HubSpot says its merged record combines activities and associations, generally favours the primary record’s property values, and applies exceptions to some contact properties. Its documented contact exceptions include keeping the lifecycle stage furthest down the funnel. Read the merge behaviour for the CRM in use before choosing a primary record or relying on a field to retain a particular value.

If the evidence is incomplete, stop at review. Mark the pair for its owner to resolve, or reject a suggestion when the records clearly belong to different people. A similarity score or matching name can help order the queue; it cannot supply missing identity evidence.

Use a worksheet that preserves the decision

Keep one worksheet entry per candidate pair. Limit access because record IDs and identity notes may be sensitive. Record:

• Candidate records: both record IDs and links, with each source and creation date.
• Match evidence: the exact email, documented address change or other specific evidence, and any contradictions.
• Data to preserve: owner, consent evidence, important notes, lifecycle stage, activities and associations requiring a check.
• Proposed outcome: merge, correct without merging, reject the suggestion or await evidence.
• Review and verification: reviewer, decision date, chosen primary record if applicable, and post-action checks.
• Upstream cause: form, import, integration or manual process to investigate, with its owner.

For a proposed merge, preserve a permitted snapshot or export of the relevant fields and associations according to your organisation’s data-handling rules. Write down which record should remain and why. Ask the relevant record owner to resolve disputed activity or associations before proceeding. After the merge, check the surviving record against the worksheet: owner, email addresses, consent evidence, notes, lifecycle stage and linked records. A snapshot helps with investigation; it does not make an irreversible merge reversible.

Correct form matching at the source

Review each form that produced a candidate. Confirm which email field it submits, whether a matching address updates an existing contact, and what happens when an address is new. Check field mappings as well as matching: a form that identifies the right contact can still change a property the team did not intend to update.

HubSpot’s form settings documentation describes a choice to create a new contact for an unknown email address. When that setting is off, HubSpot can use a browser cookie to associate a submission with an existing contact after checking the submitted address. Its documentation warns that repeated submissions from the same device may overwrite contact information. That behaviour is worth testing with separate, authorised test contacts if a shared device or kiosk is part of the workflow.

Inspect any form setting that updates lifecycle stage, and compare it with the stage shown on duplicate candidates. Change one rule at a time, record the previous setting, and test the expected cases: an existing email, a new email and a person using a different address. Confirm the resulting record and field values in the CRM. A successful form submission alone does not show that the matching decision was correct.

Make imports identify updates deliberately

Before an import, divide rows into existing contacts to update and genuinely new contacts to create. Match existing rows against a current export using the CRM’s supported identifier. In HubSpot, that may be Email, Record ID or a configured unique-value property, depending on the import. Check blank identifiers, duplicate identifiers within the file and columns mapped to fields that should not change. HubSpot notes that rows without a Record ID can create new records when Record ID is the chosen match field. Its import deduplication guide also describes how email matches update existing contacts.

Run a small, representative import first. Include an existing contact, a clearly new contact and a row with an expected exception. Inspect the actual records and import errors before running the remaining file. Keep the original file and mapping decisions so an unexpected result can be traced to its source. If the file came from another system, fix its export or transformation rule as well as the immediate spreadsheet.

Sample new records for recurrence

After changing a form or import rule, review a defined sample of newly created and updated contacts from that entry point. Include records with matching emails, changed addresses and missing identifiers. Compare them with the worksheet’s earlier cases. Record whether each submission or row created a new contact, updated the intended contact, or needs investigation.

Repeat the sample after the next ordinary form submissions or import, rather than relying only on test data. If the same pattern reappears, reopen the source-map entry and revise the matching rule or the information collected at entry. If no recurrence appears in the sample, report that limited result; it is not proof that every person in the CRM has been identified correctly.