# Skip CRM duplicate merging

This doc explains **Skip CRM duplicate merging**, what it means for your data, and what you should expect to see in HockeyStack.

***

#### What this setting does

If **Skip CRM duplicate merging** is enabled, HockeyStack will **not combine CRM company records that share a domain**.

Example:

* Your CRM has 3 Salesforce Accounts with the domain `acme.com` (regional accounts, business units, historical duplicates, etc.).
* In HockeyStack, you will also see **3 separate companies** (not 1 combined company).

This setting only changes how **CRM company duplicates** are handled. It does not change how we ingest your CRM or how we track website/intent signals.

***

#### What counts as a “duplicate” here

In this context, “duplicate” usually means **multiple CRM company records that represent the same real-world company** and share the same domain.

Common examples:

* “Acme – West” and “Acme – Enterprise” both use `acme.com`
* multiple historical accounts created over time
* separate accounts per product line or division

***

#### What you’ll notice in HockeyStack

**1) Company counts look closer to your CRM**

* You will typically see your company count match your CRM more closely.

**2) You will see more companies than before**

* This is expected, because duplicates are now shown as separate rows.

**3) Some companies may look empty**

* This is normal for duplicate records.
* Those records might still show:
  * CRM-native activity tied directly to that record (opportunities, activities, lifecycle stage, etc.)
* They might not show:
  * website visits, intent signals, or ad impressions (see next section).

***

#### Where website + intent data goes

Even when CRM duplicates are kept separate, HockeyStack still needs to decide where to attach **non-CRM signals** like:

* website activity
* intent data
* ad impressions
* enrichment data

In this mode:

* HockeyStack chooses **one “primary” CRM company record** among duplicates using our priority rules.
* The **primary** record receives the non-CRM activity.
* The other CRM duplicates will only show activity if it exists **directly on those CRM records**.

Why we do it this way:

* Non-CRM signals often arrive with only a domain (not a specific CRM record ID).
* When multiple CRM records share that domain, we need a single deterministic place to attach the signal.

***

#### Impact on reporting (what changes and what does not)

**What stays the same**

* Your CRM records still sync as usual.
* Your dashboards and reports should still work.

**What can change**

* Some rollups may look different because non-CRM activity is concentrated on the primary record instead of being spread across duplicates.
* If you compare exports over time, results may look more consistent because we are not collapsing/expanding CRM duplicates.

***

#### When to enable this

This setting is a good fit when you want:

* HockeyStack to reflect your CRM structure (including intentional duplicates for regions, business units, or historical records).
* fewer surprises when comparing counts between HockeyStack and your CRM.

***

#### Common questions

**Will this break dashboards?**

Dashboards should still load, but reporting may look different because activity will concentrate on the primary record instead of being spread across duplicates.

**Does this change how users/contacts are merged?**

No. Users are still identified primarily by email. This setting applies to **CRM company duplicates**.

**Can we control which record is “primary”?**

In some cases we can support custom hierarchy / priority rules (typically for enterprise setups).

**Do I need to reprocess data when switching this on?**

Typically, yes. Changing merge behavior usually requires reprocessing so historical signals map according to the new logic.