Your CRM says 8,412 contacts. Your email platform says 7,930. Nothing is broken. The two systems are counting different things, and the connection between them is copying a subset of records, in one direction, on a schedule, matched on email address. Everything outside that subset drifts apart by design — and the gap grows every week you add records through more than one door.
The useful reframe is this: an integration is not a shared database, it is a copy with rules. Six of them, usually — direction, trigger, scope, key, field map and conflict handling. Once you know a connector's six answers, every discrepancy you see becomes predictable, and you can tell in minutes whether you have a broken sync or a shallow one. That distinction decides whether you fix a job, change a process, or choose differently next time.
What "integrates with" actually means
A logo on an integrations page tells you almost nothing. What matters is the shape of the connection underneath it:
- Direction. One-way (A pushes to B) or genuinely two-way. Most native connectors are one-way for most fields, even when marketing calls them a sync.
- Trigger. Event-driven and near-immediate, polled on an interval, or run in scheduled batches. A polling connector cannot show you a matching number at any given moment, because the two systems are simply looking at different times.
- Scope. Almost never "all contacts". It is usually a list, a segment, a tag, or records matching a filter. Anyone who fails the filter never crosses at all.
- Key. Nearly always the email address. That single choice explains a large share of the drift, as below.
- Field map. Only mapped fields travel. Everything else — lifecycle stage, owner, custom fields, consent status — stays where it was created unless someone mapped it deliberately.
- Conflict rule. When both sides change the same field, one wins. Last-write-wins, source-of-truth-per-field, or "whichever system ran most recently" are all common, and they produce very different outcomes.
Ask those six questions about any connector and the mystery mostly evaporates. They are also the questions that separate a real integration from a checkbox, which is why the stack-building guide treats integration depth as a deciding criterion rather than a feature.
Where the two lists come apart
They define a contact differently. An email platform counts subscribers — often including unsubscribed and bounced addresses it still stores in order to suppress them. A CRM counts people, sometimes alongside companies, and may exclude records with no email at all. Two correct counts of two different populations will never match.
The email address is the key, and people are not their addresses. One person with a work and a personal address becomes two records. Someone who changes jobs becomes a new record while the old one lingers. A merge performed on one side does not merge the counterpart on the other.
Deletion rarely propagates. Delete a record in the CRM and the email platform usually keeps its copy — still stored, still suppressible, and, on per-contact pricing, still billable. This is the single most common reason a bill grows while the CRM shrinks.
Consent flows in only one direction — if at all. Someone unsubscribes in the email platform. If that status is not mapped back, the CRM still shows them as mailable, and the next import or re-sync can push them back onto a list. Beyond the deliverability damage, that is exactly the failure that consent rules exist to prevent, so it belongs in the "must verify" column, not the "nice to have" one.
Records arrive through other doors. A CSV import, a website form posting directly, a second connector, an event list, a manual add by someone in support. Any record created outside the connector's scope exists on one side only until something reconciles it.
Timing is not a bug. Batch windows, retry queues, and jobs that fail quietly mean two counts taken at the same moment reflect different states. Comparing totals on a Tuesday afternoon tells you nothing.
Suppression lists inflate one side. Hard bounces, complaints and role addresses are typically retained by the email platform so it can keep excluding them. They are in the count. They are not in your audience.
Which tool should own which fact
The fix is not making the numbers match. It is deciding, once, which system is the system of record for each fact — and treating every other copy as a cache that may be stale.
| Fact | Owner | Why |
|---|---|---|
| Consent and unsubscribe status | Email platform | It enforces suppression at send time; a copy elsewhere cannot |
| Engagement — opens, clicks, bounces | Email platform | It generates the events; the CRM only ever receives a summary |
| Deal stage, owner, pipeline value | CRM | It is where the sales process actually runs |
| Company and account relationships | CRM | Email tools model individuals, not org charts |
| Identity across multiple addresses | CRM, if it can merge | Whichever tool can merge duplicates should hold the canonical person |
| The number you are billed for | Whichever vendor bills it | Monitor it in that tool; no other count is the invoice |
Write this down and share it. Most "the data is wrong" arguments are two people quoting the correct number from the wrong system.
Is the sync broken, or just shallow?
Run this before you open a support ticket:
- Stop comparing totals. Define one segment that should exist in both systems — say, contacts created in the last 30 days with an email address and marketing consent — and compare that.
- Pick five records that differ and trace each one individually. For each, ask: does it fail the connector's filter, does it lack the key field, does a duplicate exist, was it deleted on one side, or was it created after the last successful run?
- Read the connector's own history. Native integrations and middleware both log runs and failures. A queue that has been retrying for a week explains a lot.
- Time a single change. Edit one record and watch how long it takes to appear on the other side. That is your real sync interval, whatever the marketing page says.
If all five records have an explanation inside the connector's design, the sync is shallow, not broken — and no amount of support escalation will change it. The answer is a different field map, a different scope, or a different tool.
What to check before you buy the next tool
This is where the story turns back into a purchasing decision, because a shallow connector is far cheaper to avoid than to work around:
- Ask for the six mechanics in writing — direction, trigger, scope, key, field map, conflict rule — for the specific pairing you will run, not integrations in general.
- Verify consent handling explicitly. Does unsubscribe status travel back? Does a re-sync re-add suppressed contacts? Get this one answered before anything else.
- Test the full lifecycle during the trial, with real records: create, edit, unsubscribe, bounce, delete, and merge. Watch each one on the other side. Most connectors handle create-and-edit well and fail somewhere in the last three.
- Note whether the connection is native, middleware, or DIY. A connector platform bridging two tools is a legitimate answer, but treat it as an ongoing cost and a component that can break silently.
- Check how the vendor counts for billing — stored records, or mailable ones? On per-contact pricing that definition is the difference between two invoices, which is why it sits in the pricing criteria in how to choose email marketing software.
The same logic applies from the CRM side of the pair: pipeline features get all the attention in a demo, while data capture and field-level sync decide whether the tool tells the truth six months in. That trade-off is covered in how to choose a CRM.
When a mismatch matters — and when to ignore it
Act on it when consent status disagrees, when the billed count includes records you thought you deleted, when a report used for a decision is built on the stale copy, or when a person acts on the wrong number — a rep emailing someone who opted out, or a campaign sent to a segment that no longer exists in the source.
Let it go when the difference is only in totals, when the extra records are suppressed addresses the email platform keeps deliberately, or when one system holds historical contacts the other never needed. Chasing an exact match between two tools that count different populations is work with no output.
FAQ
Which should be the master list, the CRM or the email platform? Neither, for everything. Make the CRM the master for people and deals, and the email platform the master for consent and engagement. A single master list across both is only realistic in an all-in-one suite.
Does a two-way sync solve the problem? It removes one cause and adds another. Fields now travel both directions, but you inherit conflict resolution: when both sides change the same field, something has to lose. Two-way sync without a stated conflict rule creates flapping records that overwrite each other.
Why is my email platform billing me for contacts I deleted in the CRM? Because deletion almost never propagates, and most platforms bill on stored contacts rather than mailable ones. Delete or archive in the billing system directly, and check whether your plan counts unsubscribed and bounced addresses.
Is a connector platform good enough, or do we need a native integration? Middleware is fine for low-volume, low-stakes handoffs and for pairings nobody builds natively. For your core pairing — the one carrying consent and revenue data — prefer a native, documented integration, and keep a real API as your fallback.
Would an all-in-one suite avoid all of this? It genuinely reduces it: one database, one contact definition, no sync to break. You pay for that with weaker specialist capability in each module, so it is a trade to make deliberately rather than a rule.
How often should the sync run? Fast enough for the fastest decision that depends on it. Consent changes should be near-immediate; engagement summaries can run hourly or daily without harm. Buying real-time everywhere costs money and buys little.
Two connected tools disagreeing about contacts is normal; not knowing why they disagree is the problem. Pin down the six mechanics, name an owner for each fact, and test the whole record lifecycle before you commit. When you are choosing the next piece of the stack, compare CRM and email marketing platforms side by side on Nexuswoot, where integration depth is scored alongside pricing and features. (Disclosure: Nexuswoot may earn a commission from some of the tools it compares; rankings follow the published criteria, not payouts.)
