HubSpot + Dynamics 365 Finance and Supply Chain integration

Dynamics 365 Finance and Supply Chain Management sit at the centre of groups that trade through several legal entities. Each company in the group keeps its own customers, sales orders, warehouses and posted invoices, and the group reports across all of them. The sales team in that group often runs HubSpot, chosen for marketing and pipeline, and cannot see which company a customer buys through, what is still on order, or whether the last invoice was paid.

The confusion usually starts in the marketplace. A buyer searching for Dynamics 365 finds HubSpot’s own Microsoft Dynamics 365 app and reasonably assumes it covers the ERP, but HubSpot’s knowledge base lists what it syncs: accounts, contacts and leads, opportunities, products, activities, invoices and sales orders. Those are CRM records from the customer engagement side of Dynamics 365. Finance and Supply Chain Management do not appear anywhere in that documentation.

Some of these estates began life as Dynamics AX, and integrations built on AX 2012’s document services had to be rebuilt, because Microsoft lists those services as replaced by data entities. Data entities are also what insulate an integration from changes to the tables underneath them between versions. A HubSpot integration built now reads those entities, which is the design most likely to outlast the next few updates.

The sync reads four data entities. Customers V3 becomes HubSpot companies, Sales order headers V2 becomes deals, Sales invoice headers V2 lands on a custom object, and Released products V2 becomes HubSpot products.

Customers, orders, invoices and released products each belong to a legal entity, stored as dataAreaId, and OData returns only the service account’s default company unless the request asks for cross-company data. So every key is a pair: customer account and legal entity, order number and legal entity, and so on. Where one buyer trades through two legal entities, that is two customer records in Finance, and discovery decides whether HubSpot shows one company or two.

Released products belong to a legal entity too, with the shared product sitting above them, so products key on the item number in the legal entity whose prices sales actually quotes.

The flow runs into HubSpot only. Microsoft classes posted invoices as transaction data, so the HubSpot copy is read only and updated from payment events rather than edited.

The service reads data entities through OData with change tracking, and takes business events alongside for invoices and payments. An application registered in Microsoft Entra ID authenticates with client credentials, and the Microsoft Entra applications page in Finance maps it to a dedicated service account whose roles limit what it can read. Change tracking is switched on per entity, and each read asks only for what changed since the previous one, with a position stored per entity.

The Invoice created from a sales order and Payment posted events go to an Azure Service Bus queue in the client’s subscription. A worker takes each event, checks its control number against those already processed, reads the record the event names, and passes it to the writer.

The HubSpot writer upserts in batches on number and legal entity, then a separate pass associates orders and invoices to their companies. Change tracking does not report deletions outside bring-your-own-database exports and virtual entities, so a nightly job compares keys per legal entity and closes whatever has gone.

The first question is whether Dynamics 365 Sales already runs beside Finance and Supply Chain Management. If it does, dual-write may already copy customers, quotations and orders into Dataverse, and HubSpot’s Microsoft Dynamics 365 app can sync what reaches the Sales side. Test that chain before building anything.

If it does not, a custom API integration against the data entities is the route we recommend, with business events carrying invoices and payments as they post. It needs an Entra application, read access for a service account and one Service Bus queue, all of which sit inside the client’s own Microsoft tenancy.

Power Automate can subscribe to business events directly and is fine for a single notification, such as a posted invoice updating a HubSpot property. It has no backfill, no change position and no reconciliation, so it stays a supplement rather than the integration.

1. Scope. We list the legal entities in scope, the Dynamics 365 apps running beside Finance, the business events already active, and who owns the Azure subscription that will hold the queue.
2. Architect. We fix the keys with their legal entity, the change tracking option per entity, the event endpoint and the throttling priority for our application.
3. Build. We build against the Tier 2 sandbox, and the service refuses any environment or HubSpot portal that is not on its allowlist.
4. Validate. We reconcile counts per legal entity, post a test invoice and payment to prove the event path, and delete a test order to prove the nightly comparison.
5. Operate. Cutover swaps the environment URL and the application credentials. We watch queue depth and the business events error log, and re-test in the sandbox before each update reaches production.