Duplicate records are the quiet tax on a CRM. Activity history splits across two contacts, the same person receives the same campaign twice, and reporting counts one account as three. HubSpot deduplicates on email address, which catches the obvious cases and misses most of the rest.
The harder cases are the ones that matter. The same person submits a form with a personal address after a webinar. A company exists three times because one record stored the domain with www, one with the protocol and one bare. An integration creates order records that HubSpot does not deduplicate at all because they live on a custom object.
None of this needs Data Hub Professional. It needs matching rules that understand how the data is actually shaped, and a way to see what a merge would do before it does it.
Match on what the data really looks like
Phone numbers are the clearest example. The same number arrives as +91 98765 43210, as 09876543210, and with punctuation in between. Compared as strings they are three different values, so exact matching finds nothing. Normalize first and they are obviously one number.
Domains have the same problem. Comparing website fields literally means www.example.com and https://example.com never match, so the duplicate company survives every cleanup pass.
Combine conditions when one field is not enough
Matching on a single property is often too loose. Two different people can share a company phone number, so phone alone would merge records that should stay separate. Requiring a phone number and a country to agree, or accepting an exact customer identifier on its own, expresses the real rule.
That is what the advanced rules syntax is for: properties joined by a plus sign must all match, alternatives separated by a vertical bar are considered independently.
Never merge blind
HubSpot merges cannot be undone. A deduplication rule that looked right in theory and wrong in practice is not something you can roll back, which is why the merge action defaults to preview mode and reports the record identifiers it would have merged.
Run it in preview for a week, read the outputs in your workflow history, then switch it to merge for real once the reported pairs are genuinely duplicates.
Build it
Each of these is a working pattern with the exact steps, using the actions this article describes.
Deduplication works best as a standing workflow rather than a quarterly cleanup project: enrol records on create, let the rules catch duplicates as they appear, and the backlog stops growing.