Dynamics 365 Customer Insights vs HubSpot Marketing, and Stopping the Sync Corrupting Your Data

Should you use Dynamics 365 Customer Insights or HubSpot Marketing when you already run Dynamics 365 Sales?

Decide on where customer data, consent and the hand-off to sellers need to live, not on a feature checklist. Both are capable marketing platforms. The real question for a company already on Dynamics 365 Sales is whether running marketing in a second system, joined to the CRM by a sync, is a cost you are choosing for a good reason or one you inherited.

Keeping HubSpot alongside Dynamics 365 Sales is right when marketing's daily work, website, content and reporting genuinely depend on HubSpot, when the team runs it well, and when you are prepared to treat the sync as permanent architecture with a named owner and the controls described on this page. Consolidating onto Dynamics 365 Customer Insights - Journeys is right when the two systems exist mainly through history or an acquisition, when sellers need journeys, consent and engagement on the same Dataverse contacts, leads and accounts they work, when consent must be provable from one record, or when the sync has become a recurring incident rather than a background job. What a Customer Insights - Journeys implementation covers, including consent, segments and lead hand-off to sellers, is on our Customer Insights implementation page, and the Sales side of that hand-off is on our Dynamics 365 Sales implementation page.

If the underlying question is whether to keep paying per user for licensed platforms at all, our guide to when a CRM you own beats licensing, and when it does not sets out that decision, so it is not repeated here. Features, packaging and licensing of both products change often, so compare against current Microsoft and HubSpot documentation rather than any fixed list, including this one.

If you keep HubSpot, how do you gate the sync so sales keeps trusting Dynamics 365?

Treat the sync as a set of explicit rules that protect what sellers rely on, and enforce them on the Dynamics 365 side so they hold even if the connector configuration changes later. Sales stops trusting the CRM when a value they confirmed on a call reverts, when every form fill appears as a lead, or when the same person shows up twice. Four controls prevent that, and each one is set out in detail in its own section below, so this is the summary rather than a second version.

• Field ownership: one owning system per field, recorded in a field ownership register both teams can read. Sales-owned fields such as account details, record owner, confirmed contact details and opportunities never sync back from HubSpot. See the section on deciding which system is authoritative.
• Direction: one-way by default, with two-way sync only for the few fields both teams genuinely edit, each with an explicit conflict rule, and non-owned fields made read only in Dynamics 365. See the section on one-way and two-way sync.
• A gate on which records cross: only contacts past an agreed qualification point enter Dynamics 365, enforced by integration user security and validation in Dataverse. See the section on gating which records sync.
• Dedupe on deterministic keys: stored record IDs from the other system with a Dataverse alternate key, email only as a reviewed first link, and existing duplicates cleaned before the sync is switched fully back on. See the sections on matching keys and on cleaning up duplicates.
• Proof every week: a reconciliation report marketing operations and sales operations review together, so drift is caught before sellers find it.

Why does a HubSpot and Dynamics 365 integration create duplicate and mismatched records?

Because two systems are both allowed to create and edit the same customer, and the rules for recognising "the same customer" are weaker than the business assumes. Connectors, whether HubSpot's own Microsoft Dynamics 365 integration or a custom build, do exactly what they are configured to do. When records multiply or values flip back and forth, the cause is almost always in the configuration and the data, not a random fault, and it usually traces back to a short list of patterns.

The symptom sales sees is a contact that exists twice, an account with the wrong owner or a phone number that keeps reverting. The symptom marketing sees is a list that no longer matches what sales says is a customer. Both are describing the same design gap.

• Email address as the only matching rule. Contacts with no email, a shared inbox, a changed job or a second address do not match, so the sync creates another record instead of updating the existing one.
• Company matching on website domain, which merges subsidiaries that share a domain and splits a customer whose records carry different domains or none.
• Two-way sync on every mapped field, so the last edit in either system wins and a correction in one system is quietly overwritten by an older value from the other.
• Everything syncs. Every form fill, event registration and cold list import in HubSpot becomes a lead or contact in Dynamics 365, which buries the records sellers actually work.
• Lead and contact confusion. A HubSpot contact can end up as a Dynamics 365 lead and later a contact created by qualification, with nothing linking the two back to one HubSpot record.
• Mismatched option values and owners, such as lifecycle stage, lead source or record owner, where a value with no mapping on the other side is dropped or replaced by a default.
• Automation on both sides reacting to the integration, such as a Power Automate flow or a HubSpot workflow that updates a record whenever it changes, so each sync triggers another change and another sync.
• Other routes into the same tables, such as Excel imports, email tracking or a second integration, creating records the sync then fails to match.

What should you do first when the sync is actively corrupting data?

Stop the bleeding and preserve the evidence before anyone starts merging or editing. Every hour the sync keeps running with a bad rule creates more records to untangle, and every manual fix made while it runs can be overwritten on the next cycle. Containment is quick and fully reversible: the sync can be switched back on once the design is agreed.

Do not start merging duplicates during containment. Merges in Dynamics 365 cannot be undone through the product, and a merge made while the link between the two systems is unclear can break the association the sync relies on. The merge method comes later, after the matching design is fixed.

• Pause the sync. In HubSpot's connector this is a setting in the integration's configuration, which your HubSpot administrator controls; for a custom integration, switch off the scheduled job, flow or function. Check current HubSpot documentation for exactly how pausing behaves and what happens to changes made while it is paused.
• Switch off automation that reacts to integration updates on both sides, including Power Automate flows triggered on create or modify and HubSpot workflows that write back to synced properties.
• Freeze bulk imports into the affected tables until the design is agreed.
• Take a snapshot of both systems: an export of accounts, contacts, leads and opportunities from Dynamics 365 and the matching objects from HubSpot, with record IDs, created and modified dates and who made the change.
• Check that auditing is enabled on the Dataverse tables involved, and use the audit history of the integration user to establish when the bad writes started and which fields they touched.
• Name one owner for the incident from each team, marketing operations and sales operations, so decisions are made once and not relitigated in chat.

How do you decide which system is authoritative for each object and field?

Decide per field, not per system, and write it down. "HubSpot owns contacts" and "Dynamics owns accounts" sound clear, but they break down immediately, because marketing legitimately owns consent and lead source on a contact while sales legitimately owns the job title and phone number they confirmed on a call. The unit of ownership is the field, grouped by object.

Run one working session with both teams and produce a field ownership register: for every synced field, the owning system, the sync direction, the conflict rule and who may change it. Publish it where both teams can read it, and treat changes to it as changes to the integration. The table below is a typical starting point, not a rule; the right answer depends on where your teams actually work.

When should the sync be one-way rather than two-way?

Wherever the ownership register names one owner, which should be most fields. One-way sync removes the class of problems where a stale value overwrites a correction, because the non-owning system never writes that field back. Two-way sync is only worth its risk for a small set of fields that both teams genuinely edit, and each of those needs an explicit conflict rule rather than "most recent wins".

One-way sync only holds if users cannot edit the field in the non-owning system, or they will make changes that silently disappear. On the Dynamics 365 side that means making HubSpot-owned columns read only on the forms, and using column security where an edit must be impossible rather than merely discouraged. The equivalent restriction in HubSpot is configured by your HubSpot administrator.

HubSpot's Dynamics 365 connector offers per field sync rules, typically choices such as always taking the value from one system, syncing both ways, or not overwriting an existing value, alongside default and custom field mappings. The exact options, which objects they apply to and how conflicts are resolved change over time, so check current HubSpot documentation and map each rule to a line in your ownership register rather than accepting the defaults.

How do you gate which records sync at all?

Sync the records the other team needs, not the whole database. Most HubSpot portals hold far more contacts than sales will ever work, and pushing all of them into Dynamics 365 creates the noise, the duplicates and the API load that make sellers stop trusting the CRM. The gate is a written rule, for each object and each direction, that a record must satisfy before it crosses.

On the HubSpot side, the connector provides ways to limit which contacts sync, such as sync filters based on a list or property criteria; check current HubSpot documentation for what is available on your subscription and whether filters also apply to companies and deals. On the Dynamics 365 side, the gate is enforced by the platform rather than by good intentions, so it holds even if the connector configuration is changed later.

• HubSpot to Dynamics 365: only contacts that meet an agreed qualification point, such as a lifecycle stage or a sales accepted flag, with a valid email address or another identifying key, and excluding test, spam, competitor and unsubscribed records where sales has no use for them.
• Dynamics 365 to HubSpot: only active accounts and contacts with an owner, or those explicitly marked for marketing, through a "sync to HubSpot" column users or rules can set.
• An integration user in Dataverse with a security role that allows only the tables and operations the design needs, so a misconfigured mapping cannot create records in tables it was never meant to touch.
• Server side validation, such as a plugin on create for the integration user, that rejects a record missing its matching key instead of letting an unmatched duplicate in.
• A documented rule for what happens when a synced record later falls outside the gate, for example an unsubscribed contact: stop syncing and keep, or flag for review, rather than delete silently.

How do deterministic matching keys and Dataverse alternate keys stop new duplicates?

Match on an identifier that cannot be ambiguous, and let Dataverse enforce it. Email is a useful attribute but a poor key: it can be empty, shared, changed or held in several fields. A deterministic key is the other system's own record ID, stored once and never edited by users. Store the HubSpot record ID in a dedicated column on the Dynamics 365 contact, lead and account, and store the Dynamics 365 record ID in a property on the HubSpot record, so each side knows exactly which record it is linked to.

An alternate key on the HubSpot ID column tells Dataverse the value must be unique in that table, and the platform rejects a second record with the same value whichever route it arrives through. It also makes upsert possible: a Web API PATCH request addressed by the alternate key updates the matching row if it exists and creates it if it does not, so a retried or repeated message cannot create a duplicate. Email can remain a secondary rule for linking a record the first time, normalised and routed to a review list when it matches more than one record rather than guessed.

How far this applies depends on the integration. HubSpot's own connector manages its record associations and matching logic itself, commonly with email playing a central role for contacts, so check current HubSpot documentation for how it matches and whether you can influence it. A custom integration controls matching entirely. The practical details of activating an alternate key, which cannot happen while duplicates still exist on that column, are in our guide to fixing duplicate data in Dynamics 365.

Should you use HubSpot's own Dynamics 365 connector or a custom integration?

Start by configuring the native connector properly, and build a custom integration only when the design needs something the connector cannot do. Many broken syncs are not a connector limitation at all but default mappings, two-way rules and unfiltered contact sync that nobody revisited after setup. An ownership register, one-way rules and sync filters fix a large share of them without new code.

A custom integration becomes the better choice when you need key based upsert on Dataverse, gating logic the connector cannot express, custom tables on the Dynamics side, an error queue someone watches, or processing inside your own Azure tenant. It is also a system you now own, with credentials, monitoring, retries and a named owner, which is exactly the burden our guide to rationalising point-to-point integrations describes. High volume syncs also compete with interactive users for Dataverse capacity, covered in protecting interactive users from API limits. If records are disappearing rather than duplicating, start with the integration emergency triage reference.

How do you clean up the duplicates the sync has already created?

After the matching design is fixed and before the sync is switched fully back on, and in a coordinated order across both systems. The cleanup method itself, profiling duplicates, tuning detection rules, merging in logged and reversible batches and activating alternate keys afterwards, is set out in our guide to fixing duplicate and dirty customer data in Dynamics 365, so it is not repeated here. What is specific to a HubSpot sync is the link between the two systems.

• Keep the records being merged out of sync scope while you work, so the connector does not recreate the subordinate record on its next cycle.
• Decide which system merges first. A merge in Dynamics 365 does not automatically produce the equivalent merge in HubSpot, or the reverse, so agree the order and check current HubSpot documentation for how the connector treats merged records.
• Make sure the surviving record carries the correct stored record ID from the other system, and clear or retire the IDs on the records that were merged away.
• Backfill the stored IDs on records that were linked only by email, so every in-scope record has a deterministic key before the alternate key is activated.
• Re-enable the sync one object at a time, accounts before contacts before deals, and compare the reconciliation report after each step.

What should the weekly reconciliation report show both teams?

The numbers that prove the sync is doing what the ownership register says, in a form marketing operations and sales operations review together every week. The report turns "the CRM is wrong again" into a specific list of records with a specific cause, and it catches drift before sellers notice it. It can be a Power BI report or a set of Dataverse views combined with a scheduled export of HubSpot record IDs through the HubSpot API; what matters is that both teams trust the same page.

• Record counts per object inside the agreed sync scope in each system, and the difference between them.
• In-scope records with no stored ID from the other system, meaning they have never been linked.
• Stored IDs that do not exist on the other side, meaning the linked record was deleted, merged or never created.
• Duplicate candidates on the matching key and on normalised email, created in the last week.
• Mismatches on owned fields, where the non-owning system holds a different value from the owner.
• Sync errors from the connector log or the integration's error queue, with how many are still unresolved from previous weeks.
• Changes by the integration user to fields it does not own according to the register, which should always be zero.
• The trend of each line week over week, with a named owner for anything that grew.

Is the real answer to stop running two CRMs side by side?

Sometimes, and it is worth asking honestly once the sync is contained. If marketing wants to stay in HubSpot and sales needs Dynamics 365, a well designed sync is a perfectly reasonable long term architecture, and the steps above are how it works. But if the only reason for two systems is history, consolidating removes the sync problem entirely rather than managing it.

One route is running marketing on Dynamics 365 Customer Insights - Journeys, so journeys, consent and leads live in the same Dataverse tables sales uses; what that involves is on our Customer Insights implementation page. The other route is the opposite: if the sales process is a single pipeline that only the sales team writes to, HubSpot alone may be the right amount of software, and our honest comparison of Dynamics 365 with Pipedrive and HubSpot sets out the breaking points that decide it.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. If you have outgrown a light CRM but per-user Microsoft licensing is the obstacle, a custom-built CRM on React, Node.js, PostgreSQL or .NET can own the customer record and integrate with HubSpot on keys you control.

When does a broken HubSpot and Dynamics 365 integration need outside help?

When the problem keeps coming back after your own team has tried to contain it, or when the fix needs skills the team does not have. Pausing the sync, agreeing field ownership and tightening the connector's rules are often within reach of a capable marketing operations and CRM administrator pair. Redesigning matching, enforcing the gate in Dataverse or replacing the connector usually is not, and an integration that touches customers is a poor place to learn.

Be clear about which side needs the help. Problems inside HubSpot, such as portal configuration, HubSpot workflows and the connector's HubSpot-side settings, belong with your HubSpot administrator or a HubSpot partner; Solzet does not implement or administer HubSpot. Problems on the Dynamics 365 and Dataverse side, and in the integration design between the two, are work we take on.

• Duplicates or reverting values return after a cleanup, which means the matching or direction rules are still wrong.
• Nobody can say which rule or process wrote a given value, and the Dataverse audit history has not been reviewed or is not enabled.
• The fix needs alternate keys, upsert, validation plugins, integration user security or a custom integration that nobody on the team has built before.
• A client-facing process, a key account or a sales forecast is already affected, so the repair cannot wait for internal capacity.
• Marketing and sales operations cannot agree ownership, and the decision needs a neutral party to run the session and write the register.
• A decision is pending on consolidating onto Customer Insights - Journeys, and the sync must be stabilised before that decision can be made on evidence.

How does Solzet help fix a Dynamics 365 and HubSpot integration?

We are clear about the boundary. Solzet does not implement or administer HubSpot: portal configuration, HubSpot workflows, the connector's settings on the HubSpot side and HubSpot licensing stay with your HubSpot administrator or HubSpot partner, and we work alongside them. We build and fix the Dynamics 365 and Dataverse side and the integration design between the two.

In practice that means containment support and an audit history review, running the field ownership session and writing the register, the Dataverse side of the gate (integration user security, read only and secured columns, validation plugins), stored record IDs, alternate keys and upsert, a custom integration where the native connector is not enough, the coordinated duplicate cleanup and the weekly reconciliation report. Where the sync is part of a wider Dynamics 365 Sales problem, our Dynamics 365 Sales implementation page describes the broader engagement.

The work is done by senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly for your team or white-label for Microsoft partners.