Supported Properties#

When you add a field rule to a match rule, you pick a property and Dedupify applies the right comparison logic for that field type automatically. You never choose an algorithm. This page catalogs every supported recipe and helps you understand which properties make for reliable duplicate detection.

Choosing a property automatically applies the right matching recipe.

Choosing the Right Properties#

Strong identifiers — email, phone, domain, LinkedIn URL, and external/CRM IDs — make reliable anchors for any rule. When a rule is built on at least one strong identifier, it tends to score Good or Strong and produces far fewer false positives than name- or text-only rules.

Supporting signals — first name, last name, company name, country, and generic text — work well when combined with a strong identifier or a second supporting signal. Avoid relying on any single supporting signal as the only field in a rule; the match pool is too broad.

A practical starting pattern: one strong identifier plus one or two supporting signals, with a hard rule on the identifier, produces a well-balanced rule for most use cases.

Recipe Catalog#

Email Match#

Best for: Contacts (primary email, additional email addresses).

Dedupify ignores case and leading/trailing whitespace, fixes common freemail domain typos (for example, gmial.com is treated as gmail.com), and can optionally strip plus-tags (user+tag@example.com → user@example.com) and normalize common provider aliases.

Option toggles:

• Auto-correct common email typos (gmial.com → gmail.com) — on by default
• Strip + tags from local part (alex+work@gmail.com → alex@gmail.com) — on by default

Email is one of the strongest identifiers available. Pair it with a hard rule of Exact match required on most contact rules.

Phone Match#

Best for: Contacts, Companies.

Handles international formats, country codes, extensions, and all common formatting differences (dashes, dots, spaces, parentheses). Two phone numbers that represent the same dialing sequence match regardless of how they were entered.

Option toggles:

• Allow a last-4-digits-only match as a low-confidence signal — off by default (last-4 alone is risky)

Phone is a strong identifier. Use it as an anchor or as a second identifier alongside email.

Domain / Website Match#

Best for: Companies.

Strips the protocol (http://, https://), www, subdomains, and trailing paths so that two URLs pointing to the same root domain compare as equal. TLD differences are not ignored — example.com and example.co.uk are treated as distinct.

Option toggles:

• Ignore subdomains (mail.example.com and support.example.com treated as the same domain) — on by default
• Ignore trailing slashes — on by default

Domain is a strong company identifier. Combine it with company name or a hard-rule on domain for high-confidence company matching.

LinkedIn URL Match#

Best for: Contacts, Companies.

Normalizes vanity profile slugs, numeric profile IDs, mobile vs. desktop URLs (linkedin.com/in/ vs. m.linkedin.com/in/), and trailing slashes so that all representations of the same LinkedIn profile compare as equal.

Option toggles: None — normalization is applied automatically.

LinkedIn URL is a strong identifier when populated. Because coverage is often incomplete, use it as a supporting signal or gate it with Field required so unset values do not accidentally suppress a match.

External ID / CRM ID Match#

Best for: Contacts, Companies, Deals, Tickets.

Performs an exact match on an external system identifier. Use this for any internal system ID, ERP customer number, or other unique identifier your team syncs into a HubSpot property.

Option toggles:

• Ignore whitespace — on by default
• Ignore special characters (- _ .) — off by default; useful when IDs come from systems with different formatting
• Case-insensitive — off by default

External IDs are the strongest possible identifier when reliably populated. Apply Exact match required and Field required to get maximum precision.

First Name Match#

Best for: Contacts.

Handles case differences, accent normalization, and common nickname equivalences (for example, Bill ↔ William, Kate ↔ Katherine). Two records with different but equivalent first names score as a strong field match.

Option toggles:

• Expand nicknames (Bob ↔ Robert) — on by default
• Ignore accents (José ↔ Jose) — on by default

First name is a supporting signal. Do not use it as the only field in a rule — pair it with email, phone, or last name.

Last Name Match#

Best for: Contacts.

Handles case differences, accent normalization, and common honorifics and generational suffixes.

Option toggles:

• Strip honorifics and suffixes (Jr, Sr, MD, PhD) — on by default

Last name is a supporting signal. Pair with email, phone, or first name.

Company Name Match#

Best for: Companies, Contacts (company name field).

Strips common legal suffixes (Inc., LLC, Ltd., GmbH, Corp., Co., and similar variants), normalizes punctuation and spacing, and applies fuzzy comparison to tolerate minor spelling differences.

Option toggles:

• Strip corporate suffixes (Inc, LLC, GmbH) — on by default
• Expand acronyms (IBM ↔ International Business Machines) — on by default

Company name is a supporting signal. It works well alongside domain or an external ID.

Country Match#

Best for: Contacts, Companies.

Normalizes country names and ISO 3166-1 alpha-2 / alpha-3 codes so that United States, US, and USA all compare as equal.

Option toggles: None — normalization is applied automatically.

Country is a supporting signal most useful for tightening geographic scope on rules that already have a strong identifier.

Match by Text#

Best for: Any short-to-medium text property that does not fit a more specific recipe.

Tokenizes the field value and applies fuzzy comparison that tolerates case differences, accents, word-order variations, and minor typos.

Option toggles:

• Ignore accents — on by default
• Case-insensitive — on by default

Match by Text is a general-purpose fallback. It is weak on very short fields (a single word or number) and prone to false positives when used alone. Use it as a supporting signal alongside a strong identifier, and prefer a more specific recipe when one is available.

Summary Table#

For guidance on combining these properties into a well-configured rule, see Match Rules & Recipes.