Matching rules

Finding a match is not deciding it

A rule only finds records worth comparing. When a rule matches, the records are grouped into a set for review; nothing is merged and nothing changes in Attio. Whether the records really are the same person or company is a decision you make when you review the set and, if you are sure, approve a merge.

Rules are therefore tuned to find candidates, not to prove identity. Two companies with the same name are a reasonable thing to show you, even though many will turn out to be different companies (see the Northstar Labs example).

Built-in rules

Every built-in rule starts switched on. A workspace admin can switch each rule on or off per object on the Duplicate detection rules page, and Reset to defaults returns them to the defaults.

Companies have no email rule because Attio Companies have no email attribute. Social profiles match however the URL was written: the scheme, www and tracking parameters are ignored.

Exact and similar

Every rule is exact except the similar half of Name. Exact means the values are the same after the cleanup described for each kind of value on this page, such as ignoring letter case in email addresses.

A similar-name comparison first sets aside differences that rarely mean a different person or company:

The remaining names are then scored against each other. How close they must be is the workspace's Scan sensitivity setting, set separately as Company name similarity and Person name similarity. The levels run from Broad through Flexible, Balanced and Precise to Near identical, which is the default. A broader level finds more potential duplicates, and more of them will be different people or companies.

Signals that need a name

A phone number, a company and an email domain are each shared by many unrelated people: a switchboard number, a large employer, a company's email domain. So for People these three only count together with the same name, in the rules Phone number + name, Name + company and Email domain + name. No built-in rule matches on a shared phone number alone.

Both values must be present. A record that has the phone number but no name, or the name but no phone number, contributes nothing to that rule.

Email addresses

Addresses are compared the way the mail provider treats them, with letter case ignored. Where a provider documents that two spellings reach the same mailbox, they count as the same address. At any other domain, addresses must match exactly apart from case, because a wrong merge cannot be undone.

Probable same email (provider alias) covers providers whose domains reach one account, for example gmail.com and googlemail.com, or icloud.com, me.com and mac.com. It is a separate rule because the addresses really are different and one account only probably holds both.

Domains and redirects

Company domains are compared by the registered domain. The protocol, www, paths, query strings and subdomains are ignored, so https://www.acme.co.uk/about and shop.acme.co.uk are both acme.co.uk. Free email domains such as gmail.com are never used as evidence that two companies are the same.

Redirected domains matches two different domains whose redirects land on the same website, for example an old domain that now forwards to a company's current one. Redirected email domain + name does the same for People's email domains. Some points about redirect checks:

• The lookups are done by checkredirects.io, a redirect-checking service run by Neon Deer Data Labs. While checks are on, the Neon Deer platform sends it company website domains; Sub-processors lists what it receives.
• A workspace admin can turn them off with Check domain redirects. While it is off, no domains are sent and Redirected domains finds no new matches.
• Whether they are included depends on your plan. On some plans you use your own checkredirects.io API key: sign up at checkredirects.io, then paste the key into Redirect lookup API key under Settings » Domain redirects in the Neon Deer platform and choose Save key. Until a key is set, the rule shows Off until set up.
• They run during scans, not during automatic detection in Attio. See Scans and schedules for how a first scan can leave them for the next one.

Protection against common values

Some values sit on many records without meaning those records are one company or one person: placeholders such as "Test Co" or "N/A", or one office phone number shared by a whole team. Each rule has Ignore very common values (for rules with more than one condition, Ignore very common combinations). A value, or combination, that appears on more records than the rule allows is not used as evidence, so it cannot pull many unrelated records into one set. The records can still match each other through other values and rules.

Custom rules

Add your own rules when the built-in ones miss how duplicates appear in your data. A custom rule has one to four conditions, and all of them must agree for records to match. A condition can compare a field on the record itself, or follow one relationship, for example the name of a person's company.

Location and owner fields cannot be used in a condition.

Before you can save a new rule, or a change to what a rule matches, run Preview matches to see what it would find in your records. If you change the rule afterwards, the preview reads Preview out of date until you preview again. A rule that would match a large share of your records shows a warning, and a rule that is too broad cannot be saved.

How matches become sets

• An exact rule puts every record that shares the value into one set. Three records with the same email address form one set of three.
• A similar-name set holds only records whose names all matched each other. If Ana Lopez is similar to Ana Lopes, and Ana Lopes to Anna Lopes, but Ana Lopez is not similar to Anna Lopes, the three do not form one set. A similar-name set can still hold more than two records when every pair matched.
• Matches from different rules do not chain together. Each record belongs to one set at a time. If a record also matches records in another set through a different rule, that match appears as evidence on the set for you to review instead of joining the two sets.

Why a set can hold records that look different

Every record in a set matched the others through the rule that formed it. A set can still look like it holds strangers, for two reasons. A rule needs only one value to agree, so the records can differ on every other field; the review comparison shows those fields as Different. And a custom rule that follows a relationship matches through a linked record: the two records agree because they link to the same record, and the review screen marks this as an Indirect match.

Example: two companies called Northstar Labs

Your workspace holds these two Company records. The data is invented.

1. The Name rule finds them

A scan puts the two records in a set because their names are the same. Domains, LinkedIn and Redirected domains do not match: the domains are different and, in this example, neither redirects to the other.

2. Review shows they differ

In review, Name is Same, while Domains and LinkedIn are Different. Two separate websites and two separate LinkedIn pages are strong evidence of two companies that happen to share a name. You do not merge them.

3. Decide what later scans should do

Choosing Remove from list instead only hides the set until a later scan finds the same records together again, which here it would.