Quick answer: Treat a duplicate alert as a question, not a merge instruction. Confirm that two records represent the same person or business, choose which information to retain, then verify the customer work after a small, controlled change. Two rows that look alike can still be two different customers.
Jump to: Merge-or-keep table · Worked example · Review card
For: small service teams whose CRM contains repeated contacts, conflicting owners or inflated counts. This is an editorial operating method, not a report of a customer cleanup. HubSpot is used for documented product examples; other CRMs have different rules.
- Start with identity, not spelling
- Use three outcomes: merge, keep separate, hold
- Write the intended result before making a change
- HubSpot: check the exact merge and import rules
- Worked example: fewer contacts, the same amount of work
- Verify the first result, then expand carefully
- Fix the source of repeated duplicates
- A review card you can reuse
- Useful detail: Review the pending workflow before merging
- Sources and scope
Start with identity, not spelling
A contact is a person, a company is an organisation, and a deal is a piece of potential work. Keep those questions separate. One customer asking for a website and a maintenance contract may need one contact and two deals. Merging the deals because the email address matches would tidy the screen while losing the business.
Begin with the queue that causes actual trouble: open work with conflicting owners, repeat outreach, or imports that keep creating the same customer. Name one reviewer and limit the first batch to cases they can inspect individually. A smaller list with clear decisions is more useful than a large list labelled “probably fine”.
Use three outcomes: merge, keep separate, hold
On a small screen, swipe the table sideways to see all columns.
| What you find | Suggested decision | Check before acting |
|---|---|---|
| Same person, confirmed by the account owner; two contact records | Candidate for merge | Current address, owner, history and open work agree. |
| Same name, different employers or conflicting history | Hold for review | Find independent evidence of identity. A name alone is insufficient. |
| Two people using one shared office inbox | Keep separate identities where the CRM supports them | Define how shared communications relate to each person; do not invent addresses. |
| One customer with two genuine projects | Keep separate deals | Both projects retain their own value, stage and next action. |
| A renamed business or several branches on one domain | Hold until the business structure is clear | Decide whether these are one organisation, branches or distinct entities. |
These are decision prompts, not automatic matching rules. Keep the original field values and record why a pair was accepted or rejected. A fuzzy match is useful for finding candidates. It is not a tiny detective who has interviewed your customers.
Write the intended result before making a change
- Capture the starting point. Record both IDs, relevant field values, owners, associated companies, open deals and next actions. Preserve an authorised export and any context it omits.
- Choose values deliberately. Specify the current email, phone, owner and business relationship. The newest timestamp may reflect a recent import rather than newer customer information.
- Check connected work. List forms, syncs, pending messages and automations that depend on either record. Ask the responsible operator how a merge affects them.
- Set a stop condition. If identity, retained values or downstream behaviour is uncertain, hold the pair. Do not expand the batch while investigating.
An export helps explain what changed, but it is not proof that the CRM can reverse a merge. Keep it access-controlled because it may contain customer information. Do not copy real customer data into public worksheets or unrelated AI tools to save a few minutes.
HubSpot: check the exact merge and import rules
HubSpot states that merged records cannot be unmerged. Its documentation describes combining activities and associations, with property-specific exceptions. Review those exceptions before choosing a primary record.
The same documentation distinguishes normal behaviour from its Primary ID Preservation public beta. IDs and workflow enrolment can behave differently depending on participation. Record the setting applicable to your account and check the resulting ID and pending work; do not assume another account’s instructions match yours.
For imports, HubSpot documents contact matching by email and matching existing records with Record IDs. A contact import without an email or another suitable unique identifier can create new records. Company matching through an API differs from file-import matching. See the official deduplication rules and merge behaviour for the exact route you use.
Worked example: fewer contacts, the same amount of work
Fictional example: a small agency has 120 contact records and flags six non-overlapping pairs. Each pair contains two different record IDs.
- Three pairs are confirmed to represent the same person within each pair.
- Two pairs represent different people sharing a mailbox, so they stay separate.
- One pair has conflicting history and stays in the review queue.
If each of the three approved pairs becomes one contact, the expected count is 120 − 3 = 117 contacts, assuming no other records were added or removed. Six flagged pairs do not mean six confirmed duplicates.
The three merged pairs have five distinct open deals between them. After the change, all five should still be represented, with their owners and next actions intact. A contact count of 117 does not prove that check passed. Record counts and operational checks answer different questions.
If the count is 116, investigate the extra reduction. If it is 118, inspect the merge results and concurrent additions before retrying anything. Repeating the entire batch because the total looks wrong can create a second problem.
Verify the first result, then expand carefully
Use an authorised test environment where suitable, or one approved, well-understood production pair. Have the normal operator open the resulting record and answer:
- Can I find the correct person and contact details?
- Are the expected history, company relationships and open deals present?
- Does each open job have the right owner and next action?
- Do linked systems resolve to the intended record?
- Did pending messages or automations behave as expected?
Allow for the product’s documented processing delay before treating an incomplete view as failure. Stop expansion if something is missing or unexpected. Preserve the before-and-after evidence and use the vendor’s supported recovery process. Creating a replacement contact is not automatically the same as recovering its history.
Fix the source of repeated duplicates
Write down where each confirmed duplicate came from: manual entry, an import, a form or a connected app. Then address that route. An import template may need a stable identifier; a sync may need its matching rules reviewed. Test one change with representative cases before rolling it out.
In reporting, annotate cleanup dates. Fewer contacts after a merge is not customer churn, and a corrected deal count is not a sudden sales decline. Keep your pipeline definitions and denominators consistent so a data repair does not masquerade as a business trend.
A review card you can reuse
Object and record IDs:
Evidence they represent the same entity:
Decision: merge / keep separate / hold:
Values to retain and reason:
Expected relationships, open work and owner:
Product rules and account settings checked:
Before-change evidence location:
Approved by / performed by / time:
Resulting ID and checks passed:
Exceptions and next review date:
Duplicate source and prevention action:
If you are moving data for the first time, start with our spreadsheet-to-CRM migration checklist. If the real problem is one customer with several conversations or jobs, use the shared inbox versus CRM guide before changing the data model.
Useful detail: Review the pending workflow before merging
HubSpot documents that records included in a merge are unenrolled from workflows; resulting enrollment depends on the applicable merge settings.
Duplicate cleanup can change pending operational work as well as field values. Put the next expected action beside the merge decision, and verify your account’s current ID-preservation and enrollment behavior before the pilot.
Try this:
- List any pending follow-up or workflow on both harmless sample records.
- Have the authorized operator check the merge and enrollment settings.
- Inspect the resulting record’s pending work after the pilot; explicitly restore only the action the owner approves.
Source: HubSpot: merge records. Checked October 3, 2026. The practical check is a PSL suggestion.
Sources and scope
Official HubSpot deduplication and merge documentation checked September 29, 2026; links are provided above. Product behaviour can change and may vary by object, account setting or integration. The decision table, batch method, example and review card are Practical SaaS Lab editorial recommendations, not vendor guarantees or measured customer results.
