Integrating Dynamics 365 with Azure services

By Emil Björk · Microsoft business apps consultant, Gothenburg

How Dynamics 365 plugs into Azure — Service Bus, Logic Apps, Functions, API Management, Event Grid, and the iPaaS patterns that actually work.

Reviewed May 20262 min read · 425 wordsPublished
On this page (8)

Dynamics 365 runs on Azure and inherits Azure's cloud services as natural integration neighbours. The right patterns depend on what kind of work the integration does. Three or four canonical shapes cover almost everything.

Azure Logic Apps

Microsoft's iPaaS-grade orchestration service. Logic Apps connectors for Dynamics 365 (Sales/CS/FS/etc. via Dataverse), Business Central, and Finance/SCM are mature. Use Logic Apps for asynchronous, multi-system integrations with non-trivial transformations, retries, and parallel branches. Strong fit for cross-system business processes — "when an Account is upgraded in Dynamics, provision the customer in a partner SaaS and write back the IDs to Dataverse".

Azure Functions

Serverless code, billed per execution. Use Functions for custom transformation, lightweight APIs in front of D365, and small webhooks. A typical pattern: a Function exposes a HTTP endpoint that incoming partner systems call; the Function authenticates, transforms, and writes to Dataverse via the SDK. Functions are also the natural home for plug-in alternatives — running asynchronously without consuming Dataverse plug-in resources.

Azure Service Bus

Reliable, queued messaging. Dataverse supports Service Bus integration as a step: when a record changes, Dataverse publishes a message to a Service Bus queue or topic for downstream consumers. Use Service Bus for decoupled, high-volume, asynchronous notification — Dataverse fires-and-forgets, consumers pull at their own pace. Resilient to transient consumer outages.

Azure Event Grid

Lightweight pub/sub for event-driven architectures. The newer alternative to Service Bus integration for some scenarios, especially when many independent subscribers care about the same events.

Azure API Management (APIM)

A façade in front of D365 (and other) APIs that adds rate limiting, authentication via subscription keys or OAuth, request shaping, caching, and developer-portal publication. Use APIM when external partners or many internal teams call D365 APIs, and you need centralised governance.

Azure Data Factory / Synapse / Fabric

For bulk data integration — initial migration, ongoing ETL, analytics extracts — ADF and Synapse pipelines orchestrate data movement using D365 entity connectors. Fabric is increasingly the destination for analytics workloads via Synapse Link.

The decision tree.

  • Real-time, low-volume orchestration → Logic Apps.
  • High-volume eventing → Service Bus / Event Grid.
  • Custom code or transformation → Functions.
  • API governance → APIM in front of Functions/Logic Apps.
  • Bulk data → ADF or Synapse Link.

The anti-pattern

Doing all of the above with custom code hosted in a single VM. It works for a quarter, then becomes unmaintainable. Use managed Azure services for everything; pay the small overhead premium.

Where to go next

Service by service: Azure Functions, Logic Apps, Service Bus, APIM in front of Dataverse, and Fabric. The decision that precedes all of them — low-code or Azure — is Azure vs Power Platform.

Related guides

Browse every guide in Integrations or just Data movement.

Was this helpful?

Signals which guides land and which need work. No account, no comment box — corrections go through the contact page.

Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.