HubSpot duplicate merge rules are usually assumed rather than checked, and the assumption most teams carry is wrong in a way that only surfaces after the merge is already done. The common mental model is that the “primary” record absorbs the “secondary” one and carries on with its own identity intact. That is not what actually happens, and the gap between the assumption and the mechanics matters, because a merge cannot be undone.
HubSpot Duplicate Merge Rules Start With a Surprise: Neither Record Survives
Merging two records in HubSpot does not simply keep the primary one and delete the other. Per HubSpot’s own documentation, “a new unique Record ID is created for the resulting merged record.” Neither the original primary record’s ID nor the secondary record’s ID survives the operation, a genuinely new record comes into existence, holding the combined data of both. Anything keyed specifically to the old primary record’s ID, whether a bookmarked URL, an external system storing that ID, or an integration mapping built against it, points at a record that no longer exists after the merge.
The second fact that raises the stakes on getting this right the first time: “it’s not possible to unmerge records.” A merge is permanent. There is no undo, no HubSpot-native way to split the combined record back into its two originals once the operation has completed, which makes the choice of which record to designate primary, and which property values to keep, a decision worth making deliberately rather than accepting whatever HubSpot pre-selects by default.
What Follows the Default Rule and What Doesn’t
For most properties, the rule is straightforward and does follow the primary/secondary intuition: “the primary record’s properties are selected” by default, and “to choose which property values are retained in the resulting record, click the values you want to keep.” That default, and the ability to override it field by field, covers the majority of ordinary text and dropdown properties on a record.
Several specific properties break from that default entirely, and each has its own distinct logic worth knowing before a merge, not discovering afterwards. Conversion counts do not follow a primary-wins rule at all, they add together: per HubSpot’s own worked example, “if the primary contact has submitted three forms and the secondary contact has submitted two forms, the value for Number of forms submitted will be five.” Marketing contact status keeps whichever value is more marketable, not whichever record is primary: “if one contact is set as Marketing and the other as Non-marketing, the merged contact will be set as Marketing.” Original Traffic Source keeps “the oldest value… unless the source has been manually updated,” in which case the manually updated value wins regardless of age. Legal basis properties keep “the most recent values from both contact records,” the newest consent record wins rather than the primary record’s own value, which matters specifically for teams relying on that property to demonstrate an accurate, current consent basis after a merge.
Engagement history and associations behave differently again, and more forgivingly: “all timeline activities of both records included in the merge will appear on the new record,” and “all associated records of both records included in the merge will appear on the new record.” Emails, calls, notes, and every associated deal, company, or ticket from both original records survive onto the new merged record, even though the record IDs themselves do not. This asymmetry, identity lost but content kept, is worth internalising on its own: the practical risk of a merge is almost never that data disappears outright, since HubSpot’s own rules are built to preserve activity and associations by default. The real risk sits specifically in the properties that carry non-obvious rules and in anything external that depended on the old record’s own ID rather than on the data it held.
Automatic Deduplication Isn’t Automatic Merging
“Automatic deduplication” is a phrase that gets used loosely, and the loose usage causes real confusion. Per HubSpot’s own documentation on automatic deduplication, “HubSpot automatically deduplicates contacts using email addresses, and companies using domain names,” available on “all products and plans.” What that actually means is prevention at the point of creation: a form submission or an import matching an existing contact’s email updates that existing record instead of creating a second one. It is not HubSpot going through an account’s existing database and merging duplicates that already exist there. A team that hears “automatic deduplication” and assumes their existing duplicate contacts are being quietly cleaned up in the background is assuming a feature HubSpot does not, by default, provide.
Finding and merging duplicates that already exist in an account is a separate, manual-by-default process. HubSpot’s own duplicate-detection defaults compare specific fields to surface candidates: for contacts, “First Name, Last Name, Email address, IP country, Phone number, Zip Code, and Company Name”; for companies, “Company Domain Name, Company Name, Country/Region, Phone Number, and Industry.” Reviewing and confirming those candidates is a distinct step from the automatic email/domain matching that only stops new duplicates being created going forward.
Merging itself is also not something every user can do by default, a detail to check before assuming a wider rollout of deduplication work can happen without a permissions conversation first. Per HubSpot’s own documentation, “data quality tools access and Edit permissions set to All Contacts or All companies or Super Admin permissions are required to use the duplicates manager tool.” A rep with ordinary contact-editing access, scoped to only their own records rather than the whole account, cannot open the duplicates manager at all, regardless of how obvious a duplicate pair looks from inside an individual record. That gap between “can see the duplicate” and “can actually merge it” is worth surfacing before a cleanup project kicks off, rather than discovered mid-project when most of the people asked to help turn out unable to do the one action the whole exercise depends on.
Where Teams Get This Wrong
The most common mistake is assuming the primary record’s own ID and URL survive a merge unchanged, then being confused when a bookmarked link or an external integration keyed to that ID stops resolving correctly afterwards.
The second common mistake is treating every property as following the same primary-wins default, and being surprised when a merged contact’s marketing status, form submission count, or legal basis value doesn’t match what either original record showed, because those specific properties follow their own distinct rules rather than the general default.
The third common mistake is merging records without deliberately reviewing which record should be primary and which property values to keep, on the assumption that a mistake can be fixed afterwards. It cannot; unmerging is not possible, which makes the review step before confirming the only real safety check available. That review is worth taking seriously precisely because the operation itself is otherwise fast and low-friction, a single confirmation click that produces a permanent result.
The fourth common mistake is assuming “automatic deduplication” means existing duplicate contacts are being merged in the background. It means new duplicates are being prevented at the point of creation, via email or domain matching, not that an account’s existing duplicate backlog is shrinking on its own.
The fifth common mistake is planning a dedicated deduplication push without first confirming who on the team actually has the permissions to carry it out. Merging requires data quality tools access plus broad edit permissions or Super Admin, which most individual contributors do not carry by default, so a plan built around “everyone flags and merges duplicates as they spot them” tends to stall the moment most of the team discovers they cannot open the tool at all, leaving a small handful of admins with the actual merge queue nobody else could touch.
Related Reading
For the automation side of keeping duplicates from accumulating in the first place, see Automate HubSpot Contact Deduplication with n8n. For the wider outreach consequences of duplicate data, see Handle HubSpot Outreach Without Duplicate Data. For a broader data-hygiene programme this fits inside, see HubSpot CRM Data Hygiene: Prevent Duplicates and Scale Outreach.
Go deeper: HubSpot Consultancy · RevOps Consultancy
Frequently Asked Questions
Does the primary record’s ID survive after merging two HubSpot records?
No. HubSpot creates a brand new, unique record ID for the merged result. Neither the original primary record’s ID nor the secondary record’s ID carries over, which can break bookmarks, external systems, or integrations keyed to the old primary record’s ID.
Can a HubSpot merge be undone if the wrong record is chosen as primary?
No. HubSpot’s own documentation states plainly that it is not possible to unmerge records. The operation is permanent, which is why reviewing which record should be primary and which property values to keep matters before confirming, not after, since there is no built-in way to split the two records apart again once the merge completes.
What happens to marketing contact status when merging two HubSpot contacts?
The merged record keeps whichever status is more marketable, regardless of which record was primary. If one contact is Marketing and the other Non-marketing, the merged contact ends up Marketing, following its own distinct rule rather than the general primary-wins default.
Does HubSpot’s automatic deduplication merge existing duplicate contacts?
No. HubSpot’s automatic deduplication uses email addresses for contacts and domain names for companies to prevent new duplicates being created during imports or form submissions. It does not go through an account’s existing database and merge duplicates that already exist there; that requires a separate, manual review process.