HubSpot + Dynamics 365 Sales integration

In Dynamics 365 Sales, an opportunity is a row in Dataverse, the same store that Customer Service, Power Apps and Power Automate flows read and write, so it can feed processes well beyond the sales team. When marketing chooses HubSpot, the real question is how much of that shared record HubSpot should be allowed to touch.

What each side cannot see is concrete. A seller working an opportunity cannot see which emails the contact opened or which form brought them in. A marketer building a nurture list cannot see which accounts already have an open opportunity, so the list includes people a seller is about to close. HubSpot’s app answers both halves: it pairs the records in the two systems, and its HubSpot Embed feature puts a record’s HubSpot timeline and workflow enrolments inside the Dynamics form, where a seller can also enrol the contact in a sequence.

Scope is the decision that shapes the project. If Dynamics is staying, this is an integration, and every synced field needs one owner. If Dynamics is being retired, it is a migration with a sync for the months in between, and the migration or integration guide is the place to start before anything is configured.

HubSpot’s app works table by table, and each pairing gets its own direction. Accounts become companies, opportunities become deals, and tasks and appointments move both ways as activities. Phone calls and emails logged in Dynamics come into HubSpot one way. Custom tables pair with HubSpot custom objects on Enterprise subscriptions, and a sales order raised from a HubSpot deal comes back as a HubSpot order.

Contacts are where the matching needs thought. Dynamics keeps leads and contacts in separate tables, and HubSpot’s app offers both against the one HubSpot contact object, matched on email. A person held in both tables therefore competes for a single HubSpot record. We decide which table feeds HubSpot before the first sync rather than learning it from the list of failing records.

After the first match, data sync holds each pair by record id, so a renamed account or a changed email does not split it. Deal pipelines and stages are mapped by label, only opportunities in mapped stages sync, and a task linked to a Dynamics lead only ever moves into HubSpot.

With the app there is no runtime to host. When a sync is switched on, HubSpot indexes every record on both sides, pairs what matches, then works incrementally; its documentation says a change syncs within ten minutes once the initial sync is complete. A conflict setting per table names the system whose value wins, and a filter limits which records enter the sync.

Where custom work is needed, it sits beside the app on a watermark. A service registered in Microsoft Entra ID calls the Dataverse Web API as an application user, asks for changes with the odata.track-changes preference, and stores the delta link each response returns as the watermark for that table. Deleted rows arrive in the same response, marked as deleted. Writes into HubSpot are batch upserts keyed on the Dataverse id, followed by a separate association pass. Writes into Dataverse go through an alternate key, so a replayed batch updates the same row instead of creating a second one.

Three facts decide the route for Dynamics. First, where the organization runs: HubSpot’s listing says the app supports only cloud domains on dynamics.com, so an on-premises Customer Engagement server rules it out. Second, whether email, company name and domain are good enough match keys; where HubSpot offers it for a table, the app can match on a text field you choose instead, but only for records not yet paired. Third, the HubSpot tier, since custom field mappings need a paid Data Hub subscription and custom object sync needs Enterprise.

When all three favour the app, configuration beats code. We steer away from a per-task automation platform in the middle: its flows sign in as one Dataverse user, so every call lands on one user’s service protection budget, and it charges per record for work the app already does.

1. Scope. We confirm the organization is on dynamics.com, list the tables in scope, and count the people held as both leads and contacts.
2. Architect. One owner and one direction per table, the conflict winner, the pipeline and stage map, and the match keys, written down before anything is switched on.
3. Build. HubSpot’s app is configured first against a Dataverse sandbox environment, which needs a gigabyte of free capacity, or against a filtered subset where none exists.
4. Validate. We compare counts per table, spot check paired records, and test the conflict rule by editing one field on each side.
5. Operate. We review the failing and excluded records in HubSpot’s sync health view every week, and alert on any custom watermark that stops advancing.