Integrating Dynamics 365 with HubSpot: marketing sync patterns

A common landscape: marketing runs HubSpot, sales runs Dynamics 365 Sales, and the two teams need leads, contacts, and engagement to flow between them without a nightly spreadsheet. HubSpot is popular enough that this integration is well-trodden, and the patterns are clear. The question is less "can it be done" and more "which of the three ways to do it matches how much you care about data quality".

If the question is whether to keep HubSpot at all or move marketing onto Customer Insights - Journeys, that is a different discussion: see Customer Insights - Journeys vs HubSpot.

Pattern 1: HubSpot's native Dynamics 365 sync

HubSpot ships a Dynamics 365 integration in its marketplace, managed from the HubSpot side. It syncs contacts, companies, and deals (mapped to opportunities) in either direction, with field mappings you configure in HubSpot and sync rules that decide which system wins for each field.

What it does well: it exists, it is supported by HubSpot, marketing can administer it without a developer, and for the standard objects it gets a mid-sized organisation running in a day.

Where it stops: custom Dataverse tables, complex ownership rules, and anything that depends on Dynamics 365 business logic firing correctly. The sync writes through the Dataverse API as an application user, so plug-ins and flows do fire, but the sync engine has no idea about your business process flow stages or your lead qualification rules. Activity sync is limited. Field mapping is per-field and does not support transformations beyond simple ones, so a picklist that differs between the two systems needs manual alignment.

For most organisations this is the right starting point. Try it before building anything.

Pattern 2: Power Automate with the HubSpot connector

The Power Automate HubSpot connector plus the Dataverse connector lets you build the sync yourself as flows. This buys you control over exactly what triggers what, transformation logic in the flow, and the ability to involve custom tables and Dynamics 365-specific concepts such as lead qualification.

The cost is that you now own a sync engine built from flows. Retries, conflict handling, and backfills are yours to design, and a bulk update on the HubSpot side will trigger a flood of flow runs that can exhaust your daily limits. This pattern suits a narrow, well-defined feed, such as "new marketing-qualified leads in HubSpot become leads in Dynamics 365 with these five fields", rather than a full bidirectional contact sync. See Power Automate connectors for Dynamics 365 for the platform's limits.

Pattern 3: iPaaS or custom code

Boomi, Workato, Zapier, Make, Azure Functions against both APIs. The right answer when the data model is genuinely bespoke, when volumes are high, or when you need one integration platform across many systems anyway. Rarely justified for HubSpot alone.

The lead hand-off is the design problem

Whatever the tooling, the decision that matters is where the lead lives at each stage. The pattern that works:

• HubSpot owns the contact while it is a marketing prospect. Email engagement, form fills, and scoring stay in HubSpot.
• When HubSpot marks the contact as marketing-qualified, a lead is created in Dynamics 365 with the HubSpot contact ID stored on it.
• Sales works the lead in Dynamics 365. Qualification creates the account, contact, and opportunity.
• The resulting Dynamics 365 contact and account are pushed back to HubSpot with their Dataverse IDs, so future marketing activity can be attributed and so HubSpot stops treating the person as a prospect.
• Opportunity stage and closed outcome flow back to HubSpot for marketing attribution reporting.

The two mistakes are syncing every HubSpot contact into Dynamics 365 as a lead, which fills the CRM with people sales will never call, and syncing nothing back, which leaves marketing blind to what happened after the hand-off.

Matching and duplicates

Email is the natural match key and it is the wrong one to rely on alone. People use multiple addresses, shared inboxes exist, and HubSpot's contact model is person-centric while Dynamics 365 separates leads from contacts. Store the cross-system IDs explicitly on both sides, use a Dataverse alternate key for upserts, and run duplicate detection rules on the Dynamics 365 side as a safety net.

Consent and unsubscribes

Marketing consent must be a single source of truth. If HubSpot manages consent and Dynamics 365 users can also send bulk email, an unsubscribe in one system must reach the other within a time the legal team accepts. This is the one field that should sync in both directions promptly, and it deserves its own monitoring.

What breaks in practice

Ownership. HubSpot owners and Dynamics 365 users are separate identity sets; map them explicitly and decide who owns records when the mapping fails.

Company matching. HubSpot creates companies from email domains automatically; Dynamics 365 accounts are created by people. Expect a reconciliation exercise in the first month.

Sync loops. A field updated by the sync triggers a flow that updates a field that triggers the sync. Mark integration writes with an application user and filter on it.

Stability verdict

The native HubSpot sync is stable for standard objects and is where most organisations should stay. Custom-built syncs are stable when narrow and fragile when they try to mirror everything. Sync the hand-off, not the databases.