Dynamics 365 tends to be the system that was already there. Finance runs on it, operations built a decade of process into it, and then marketing buys HubSpot because Dynamics marketing was never the reason anyone chose Dynamics. Now two CRMs hold overlapping records and someone has to decide which one is right.
HubSpot's own connector does more of that job than most people expect, and it costs nothing to install. It also stops in places that are specific rather than vague, and the specific places are worth knowing before you scope anything, because one of them is whether it can see your Dynamics at all. This guide covers what the HubSpot Dynamics 365 integration syncs, how to connect it, the limits both documented and structural, and how to tell when a Microsoft-shaped data model has outgrown a mapping tool. It sits alongside the broader guide to HubSpot integrations, focused on the connection that enterprise and mid-market teams ask about most.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Does HubSpot Integrate With Microsoft Dynamics 365?
Yes. HubSpot ships a first-party Microsoft Dynamics 365 app, installed from the HubSpot App Marketplace and built on the same data sync engine that powers its Salesforce, Xero and QuickBooks connectors.
Once it is authenticated against your Dynamics subdomain it does three things. It keeps the core CRM objects in agreement, so companies match accounts, contacts match contacts and leads, and deals match opportunities. It carries activity across, meaning meetings, notes, tasks, emails and calls appear on the record in both systems rather than in whichever tool the rep happened to be in. And it reaches into the commercial objects, invoices and sales orders, which is the part that makes the connection useful to anyone outside marketing.
You can connect up to two Dynamics instances with the same syncing capability on each, which covers the common sandbox-and-production pattern and the slightly less common two-business-units pattern.
What the Native HubSpot Dynamics 365 Integration Syncs
The integration is a mapping between object pairs, and the direction is set per pair. Each one can sync between apps, sync only to HubSpot, or sync only to Dynamics. This table is the most useful thing to internalise before you scope anything, because the shape of the list tells you which Dynamics it was designed for.
| HubSpot | Dynamics 365 | Notes |
|---|---|---|
| Companies | Accounts | The cleanest pair, matched on normalised name |
| Contacts | Contacts and Leads | One HubSpot object, two Dynamics tables |
| Deals | Opportunities | Pipeline and stage mapping is manual |
| Products | Bundles and Products | Catalogue alignment for quoting |
| Orders | Sales orders | Can be created from a deal or a workflow |
| Invoices | Invoices | Billed revenue visible in the CRM |
| Meetings | Appointments | Activity, not just records |
| Calls | Phone calls | Activity, not just records |
| Emails | Emails | Activity, not just records |
| Notes | Notes | Activity, not just records |
| Tasks | Tasks | One-way only when tied to Dynamics leads |
| Custom objects | Entities | Enterprise tier, and associations are dropped |
Record matching normalises the fields it compares, ignoring capitalisation and special characters in names. That is more helpful than it sounds in a Dynamics context, where account names carry legal suffixes that nobody types consistently, but it is still name matching, and name matching produces the duplicates you would expect when the same company appears as a trading name in one system and a registered entity in the other.
The permissions detail worth reading twice
The Dynamics side needs Read permissions for every record type you want to sync, and Read plus Write for anything you want to sync two-way. That sounds administrative and is actually the most common reason a first sync half works.
Dynamics security roles are granular in a way HubSpot's are not, and they are frequently scoped by business unit. A role that can read accounts across the organisation but only write to its own business unit produces a sync that pulls everything in and pushes almost nothing back, silently, on a per-record basis. Set up a dedicated service account with an explicitly scoped role before the first sync rather than debugging it afterwards.
Core CRM objects
Accounts, contacts, leads and opportunities are the reason most teams install this. The mapping is sensible and the sync is close to real time, so a rep looking at HubSpot is not looking at yesterday's Dynamics.
Contacts and leads in one object
HubSpot has one contact object where Dynamics has both contacts and leads, so this pair carries a modelling decision rather than a mapping. Decide what a Dynamics lead becomes in HubSpot before you turn it on, because reversing it later means unpicking lifecycle stages across the whole database.
Activity across both systems
Meetings, calls, emails, notes and tasks all have a pair, which means the timeline on a record is not half empty depending on which system the person who touched it was working in. This is the underrated half of the integration.
Orders and invoices
HubSpot orders map to Dynamics sales orders and can be created from a deal record or through a workflow, and invoices have their own pair. This is what puts committed and billed revenue next to pipeline in the CRM instead of in a monthly export.
How to Connect HubSpot and Microsoft Dynamics 365
Setup is configuration rather than code, which is why it is quick and also why it can only ever do what its makers built.
1. Sort out the Dynamics service account first
Create a dedicated user in Dynamics with a security role scoped to exactly the record types and business units you intend to sync, Read for one-way and Read plus Write for two-way. Doing this first turns an entire class of silent sync failures into an error you never see.
2. Install from the App Marketplace
Find the Microsoft Dynamics 365 app in the HubSpot App Marketplace and install it. You need to be a super admin or hold App Marketplace Access permissions in HubSpot.
3. Connect using your Dynamics subdomain
Enter the subdomain of the Dynamics instance you are connecting and authenticate. Note which instance you are pointing at, because you get two connections in total and a sandbox spent by accident is awkward to reclaim.
4. Decide what a Dynamics lead becomes, before you enable contacts
Contacts and leads both map into HubSpot's single contact object. Settle the lifecycle stage model, the ownership rule and what happens on lead qualification while it is still a conversation rather than 40,000 records.
5. Turn objects on one at a time, with filters, then map fields
Companies first, then contacts, then deals, then activity, then the commercial objects. Each pair gets its own direction and its own filters, and the filters only limit which records sync initially, so scope them before the first run. Custom field mappings require a paid Data Hub subscription.
Step 5 deserves more thought than it usually gets, for a reason specific to Dynamics. Dynamics deployments are almost never stock. Ten years of customisation means custom fields on every standard table, and the default mapping set covers a fraction of them. In practice, "the app is free" and "we need a paid Data Hub subscription to map our own fields" arrive in the same week.
Which Dynamics 365 Are You Actually Connecting?
This is the question that decides whether the rest of this guide applies to you, and it is the one most often skipped, because Dynamics 365 is a product family rather than a product.
The native app is built for the Dataverse side of that family: Dynamics 365 Sales, Customer Service and the other Customer Engagement apps. The object list proves it. Accounts, leads, opportunities, appointments and phone calls are Dataverse tables. If your Dynamics is Dynamics 365 Sales, everything below applies.
Business Central and Finance and Operations are different products with different data models. HubSpot's first-party app does not connect to them. The marketplace answer there is a paid third-party connector, Commercient and Rapidi being the two most commonly deployed, or a custom integration built against the Business Central or F&O APIs directly. On-premises Dynamics is not supported by the native app either, cloud-hosted only.
Plenty of teams say "Dynamics" and mean the ERP finance runs on. The free HubSpot app cannot see it. That single distinction reroutes more integration projects than any technical limit in this guide.
Where the Native Dynamics 365 Integration Stops
Some of these limits are in HubSpot's documentation. The rest you find in production. Both lists matter, and the second one is more expensive.
The documented limits
Tasks are conditional. Tasks sync one way only when they are associated with Dynamics leads, and a HubSpot task has to be associated with another record to sync across at all. An unassociated task simply does not travel.
Sales order pricing does not follow the deal. Change a line item price on a HubSpot deal after a Dynamics sales order has been created from it and the change does not sync. The order keeps the price it was born with, which is a reconciliation problem rather than a sync problem.
Order sync is a prerequisite, not an option. Sales order creation from deals only works if the corresponding order sync is configured. Skipping it produces a feature that appears to be available and silently does nothing.
Custom mappings are gated, and custom objects more so. Mapping anything beyond the default field set requires a paid Data Hub subscription, and syncing HubSpot custom objects to Dynamics entities requires an Enterprise tier. The app is free, using it against a customised Dynamics is not.
Custom object sync drops associations. HubSpot's documentation is explicit that associations are not maintained when a custom object syncs. The records arrive, the relationships do not.
Cloud only, two instances maximum. On-premises Dynamics is not supported, and you can connect at most two instances. Groups running an instance per region are outside that from the start.
The native app maps fields between two CRMs. It does not reason about them. Everything Dynamics expresses as a relationship or a constrained choice arrives flattened or not at all.
The limits nobody warns you about
Option sets degrade to text. Dropdown, radio select, multi-select and checkbox fields do not sync two-way. They flow one way into text fields, which means the constrained vocabulary Dynamics enforces arrives in HubSpot as free text and stops being safe to build workflows, routing or reporting on.
Lookup and reference fields do not carry across. Dataverse models relationships as lookups, and lookups are how a Dynamics deployment encodes most of what it knows. Territory on an account, parent account on a subsidiary, price list on an opportunity. None of it arrives natively, so the fields your Dynamics team considers structural are exactly the ones missing in HubSpot.
Direction is object-level, not field-level. You cannot two-way sync a contact while pinning owner or lifecycle stage to a single system of record. Protecting one field means dropping the whole object to one-way or building matching workflow guards on both sides, and paired workflows across two CRMs is how sync loops begin.
Pipeline and stage mapping is yours to maintain. Deals map to opportunities, but HubSpot pipelines and Dynamics business process flows are different mechanisms. The mapping is manual, and it silently rots every time either team edits their stages, which both teams do without telling the other.
The lead and contact model has to be decided, not mapped. Two Dynamics tables collapsing into one HubSpot object is a business decision about qualification, ownership and lifecycle. The connector will do whatever you configure, including a version that quietly creates a duplicate contact for every qualified lead.
Contact volume is a pricing event. A mature Dynamics database is large and full of records nobody intends to market to. Syncing it unfiltered moves you up a marketing contacts tier, and the invoice arrives well after the person who ran the sync has moved on.
None of this makes the app bad. It is a free, general-purpose connector that has to work for every Dynamics instance on earth, and it does the common case well. The point is that the common case is a lightly customised Dynamics 365 Sales instance with standard fields, one region and simple pipelines. Enterprise Dynamics deployments break all four, and they break them on day one rather than gradually.
HubSpot Dynamics 365 Integration: Native vs iPaaS vs Custom
There are three ways to bridge HubSpot and Dynamics, and they are layers rather than rivals. If the middle term is unfamiliar, the guide to iPaaS covers it properly, and the Operations Hub guide explains where HubSpot's own data sync layer draws its line.
Free, fast, maintained by HubSpot, and it puts opportunities and activity in both systems for nothing. Start here always. If your Dynamics is close to stock and marketing just needs to see what sales sees, you may never need anything else.
Useful for reaching a single lookup field or a custom entity the native sync ignores, or for proving a piece of logic earns its keep before anyone builds it properly. Costs scale per task and reliability degrades as branches multiply, so treat it as a prototype layer rather than the thing two CRMs depend on.
Built against the Dataverse Web API and HubSpot's API directly, so option sets stay constrained, lookups resolve into real associations, custom entities arrive with their relationships intact, and each field has an explicit system of record. Fixed cost, no task meter, monitored like infrastructure.
When to Build a Custom HubSpot Dynamics 365 Integration
Almost nobody should start with a build. The native app is free and the correct first move. The skill is recognising the moment you have crossed its line, and with Dynamics that moment tends to arrive earlier than with other systems, because Dynamics deployments are customised by default.
Signs you have outgrown the native Dynamics app
Your Dynamics is Business Central or Finance and Operations. There is no configuration that extends the native app to reach them. If the system your revenue data actually lives in is the ERP rather than Dynamics 365 Sales, you were never inside the connector's scope.
Option sets drive routing or reporting. When territory, segment, product line or status is a Dynamics option set that assignment rules and dashboards depend on, a one-way sync into a free text field is not a partial solution. It is a field nobody can trust on the HubSpot side.
Custom entities have to keep their relationships. Subscriptions, assets, projects, contracts and installed base are the entities worth syncing, and they are worth syncing because of what they are attached to. Records without associations are a table, not an integration.
Different fields need different systems of record. Real deployments want Dynamics to own account hierarchy and credit status while HubSpot owns lifecycle stage and marketing consent, on the same record, at the same time. That is field-level ownership, and object-level direction cannot express it.
More than two instances, or one of them on-premises. Multi-region groups and hybrid deployments are outside the connector's shape entirely, and consolidating several instances into one HubSpot portal with the source preserved is deduplication logic rather than mapping.
Both teams are running reconciliation spreadsheets. The clearest signal is behavioural. When sales ops exports Dynamics monthly and marketing ops exports HubSpot monthly so that someone can compare them, the sync is already not trusted, and everything downstream of it is being done twice.
If several of those are true, the next step is not shopping for a different connector. It is scoping the specific gaps and leaving everything the native app handles exactly where it is. Most teams that commission a build keep the free Dynamics app running for companies, contacts and activity, and add a custom layer for option sets, lookups, custom entities and field-level ownership. That is the same pattern the HubSpot Salesforce integration guide describes for the other enterprise CRM, and the HubSpot NetSuite integration guide describes on the ERP side.
One thing to know before you scope a build
Dataverse enforces service protection limits per user, per web server, on a five-minute sliding window: 6,000 requests, 1,200 seconds of combined execution time, and 52 concurrent requests, returning a 429 with a Retry-After header when you cross any of them. Those sit separately from the API entitlement limits attached to your licences, so passing one does not exempt you from the other.
It is worth knowing because it shapes the architecture rather than decorating it. Backfilling years of accounts, opportunities and activity from a mature Dynamics instance is exactly the workload those limits exist to throttle, so any serious build needs batching, backoff that honours Retry-After, and a historical import designed to run inside that budget rather than fight it. It is also a fair question to ask anyone quoting you for the work, because the answer separates people who have integrated Dataverse from people who have read about it.
What a Custom HubSpot Dynamics 365 Integration Costs
The native app is free, so the cost conversation only opens once it cannot do the job. When it does, the honest comparison is not build versus free. It is build versus the running cost of the workarounds you already have: the paid third-party connector priced per record, the per-task iPaaS bill, the monthly reconciliation export, and the routing rules that fire on a text field nobody trusts.
A custom integration is a one-time build plus ongoing maintenance, priced by scope. One-way opportunity sync into HubSpot for reporting is a smaller build than bidirectional sync across two instances with option set fidelity, lookup resolution, custom entity associations and field-level system-of-record rules. The cost teams underestimate is never the build. It is maintenance, because Dynamics customisation never stops, security roles change, and an unowned sync between two CRMs drifts until both are confidently wrong in different directions.
A custom build inverts the cost curve of a per-record connector. You pay more up front and then nothing per record, so the larger your Dynamics database, the more the economics favour building it properly.
That inversion is why we productised it. StackTie builds the connection against both APIs directly for a fixed fee and maintains it on a flat monthly retainer, so a sync carrying two CRMs' worth of revenue data keeps working without a task meter running or an owner going missing.
Native Dynamics app not reaching your option sets, lookups, or custom entities?
When Dynamics is your ERP as well as your CRM, when option sets drive routing, when custom entities have to keep their relationships, or when different fields need different systems of record, that is a build. StackTie builds custom HubSpot Dynamics 365 integrations for a fixed fee and maintains them on a flat monthly retainer, alongside the free app you already have. Live in 14 days or it's free. Book a free audit and we'll map exactly which gaps are worth closing.
The Bottom Line
HubSpot integrates with Microsoft Dynamics 365 through a free first-party app that syncs twelve object pairs, from companies and accounts through to sales orders and invoices, with a direction setting per pair and near real-time updates. Install it first. For a lightly customised Dynamics 365 Sales instance it is the right answer and a custom build would be waste.
It stops in two tiers. The documented limits are conditional task syncing, sales order pricing that does not follow the deal, gated custom mappings, custom object sync that drops associations, and a hard ceiling of two cloud instances. The structural ones are the expensive ones: option sets that arrive as text, lookup fields that do not arrive at all, direction it can only set per object, and an entire half of the Dynamics product family, Business Central and Finance and Operations, that it cannot see. Every one of those is a relationship or a rule, and mapping is neither. Keep the free app for everything it covers well, and build the specific layer it structurally cannot reach, because in a Microsoft-shaped data model that layer is usually where the business logic lives.
