Domain Matching for Salesforce Integration: How It Works

When N.Rich syncs with Salesforce, we match each Salesforce Account to an N.Rich account using domains. This article explains exactly how that matching works, including the normalization rules, so you can prepare your Salesforce data with confidence.

The matching rule

For an Account to sync successfully, both of the following need to be true:

1. The Salesforce Account Website field contains a valid company domain (e.g. https://www.ibm.com).

2. At least one Contact linked to that Account has an email address whose domain matches the Website domain (e.g. alice@ibm.com).

If both conditions are met, the account is mapped and synced. The account will not sync if:

• The Website field is empty, invalid, or a non-company domain (e.g. gmail.com, linkedin.com)

• No Contact has a matching email domain

• The Website domain and Contact email domain don't match

A placeholder Contact email is fine for this purpose - the mailbox itself is never validated or contacted. Only the domain needs to be correct.

How domains are normalized before comparison

Before comparing, we clean up both the Website field and the Contact email so that formatting differences don't cause a false mismatch. Here's exactly what happens:

We also check that what remains is a real, valid domain (using public-suffix validation), which is what filters out free-mail or ISP-style domains like gmail.com from being used as a match.

What is not changed: subdomains and multi-part domains

This is the part that trips people up most often, so it's worth calling out clearly.

Subdomains are matched exactly as they appear — they are not reduced to a root domain.

If the Website field is shop.company.com, we compare against shop.company.com as-is. We do not simplify it to company.com. This means the Contact email domain needs to match that subdomain exactly, not just the root domain.

This also means N.Rich doesn't apply any corporate-hierarchy logic: a parent company and its subsidiary won't match just because they're related. In one real case, bmw-carit.de (a subsidiary's domain) and bmw.de (the parent's domain) never matched, simply because they're different strings — not because of anything wrong with the setup.

Multi-part TLDs (.co.uk, .com.br, etc.) don't need special handling. We don't split a domain into "registrable part + TLD" for comparison — the full domain string is matched exactly. For example, https://www.company.co.uk normalizes to company.co.uk, and matches a Contact on company.co.uk the same way any other domain would — no extra steps needed on your end.

Quick reference: what to do on your side

• Make sure the Salesforce Website field contains a real company domain — protocol, www., and any path or query string are handled automatically, so you don't need to pre-clean those.

• Make sure at least one Contact on the Account has an email on that same domain — a placeholder address is fine, as long as the domain is correct.

• If the Website field uses a subdomain (e.g. shop.company.com), make sure the Contact's email uses that same subdomain — not just the root domain.

• Case doesn't matter (IBM.com and ibm.com are treated the same), and multi-part TLDs like .co.uk don't need any special formatting.

If you're integrating or generating Salesforce data programmatically (for example, syncing from another system into Salesforce ahead of the N.Rich sync), the safest rule is: whatever domain appears in the Website field, use that exact string — subdomain included — as the domain for at least one Contact's email.

What's next

• Setting up the integration for the first time? Follow the Salesforce Integration guide to complete the prerequisites — the matching rules on this page only apply once the integration is connected.

Need help at any point? Reach out via the chat in the bottom-left corner of the N.Rich platform - our support team is happy to walk you through it.