Integration Patterns

Integrating Microsoft Dynamics 365 with other systems is a common requirement. Dynamics 365 typically sits at the centre of business processes and must integrate data with ERPs, finance systems, data warehouses, legacy platforms, third‑party products, and custom applications. Choosing the right integration pattern and technology is critical to achieving scalability, resilience, security, and maintainability.

This page summarises common integration patterns used with Dynamics 365, examples of when to use them, the key Power Platform and Azure integration technologies available, and recommended best practices.

Common Integration Patterns

1. Synchronous Request (API-Based)

The API-based integration pattern is a synchronous request-response approach where one system calls an API exposed by another system and waits for an immediate response. In Dynamics 365, this is typically implemented using the Dataverse Web API, allowing external systems to create, read, update, or delete records and invoke custom actions in real time. This pattern is well suited to scenarios where instant feedback is required for the user, such as creating a Case and returning a reference number to give to a customer over the phone.

While this is a simple approach, it potentially introduces a dependency between systems. Performance and availability of the calling system are directly affected by Dynamics 365 response times, API limits, and failures. For this reason, API-based integration should only be used for genuinely real-time requirements, with asynchronous or event-driven patterns preferred for high-volume, background, or non-critical processes.

When to use:

• Real-time validations
• User-driven actions
• Scenarios where an immediate outcome is required

Examples:

• An external service creating a Case record in Dynamics 365 and immediately displaying the reference number to the user
• Validating organisation details in real time before an application is submitted

2. Asynchronous Messaging

The asynchronous messaging integration pattern enables systems to communicate by sending messages that are processed independently and at a later time, without requiring the sender to wait for an immediate response. In Dynamics 365, this pattern is commonly used alongside messaging or event technologies, allowing changes in data to be published as messages for downstream systems to consume. This approach is well suited to background processing, high-volume updates, and scenarios where immediate user feedback is not required.

By decoupling the sender and receiver, asynchronous messaging improves scalability, resilience, and exception handling. If Dynamics 365 or a downstream system is temporarily unavailable, messages can be retried or processed once service is restored. However, this pattern typically requires careful design around message formats, ordering, retries, and idempotency, as outcomes are not immediate and failures may surface later meaning messages may need to be re-processed in a different order.

When to use:

• Non-blocking operations where systems are decoupled
• High-volume background processing
• Improved resilience and scalability

Examples:

• Publishing a message when an organisation record is updated for downstream synchronisation
• Sending case updates to another system without impacting user experience

3. Publish and Subscribe (Event-Driven Integration)

The publish and subscribe integration pattern is an event-driven approach where Dynamics 365 publishes events and one or more subscribing systems react to them independently. The publishing system has no awareness of who consumes the event, which enables one-to-many integrations and loose coupling. This pattern is well suited to scenarios where multiple downstream systems need to respond to the same business change, such as an update to a contact record which is used in multiple applications.

This approach improves scalability and extensibility, allowing new subscribers to be added without impacting Dynamics 365 or existing integrations. However, this means consumers must handle the design for elements such as retries and idempotency. This pattern is ideal for broadcasting data, but less suitable where immediate confirmation or guaranteed processing is required.

When to use:

• One-to-many integrations broadcasting data
• Event-driven architectures
• Near real-time data propagation to multiple systems

Examples:

• An grant approval event triggering updates to finance, compliance, and analytics systems
• Multiple downstream services reacting to the same business event

4. Batch Integration

Batch integration is a pattern where data is exchanged in bulk at scheduled intervals, rather than processed continuously or in real time. It is commonly used for large data volumes, reporting, reconciliation, or reference data updates, such as nightly exports to a data warehouse or periodic imports from external systems. While efficient and simple to operate, batch integration introduces delayed availability of data and is not suitable for time‑critical scenarios.

When to use:

• Large data volumes
• Reporting and reconciliation
• Non-time-critical scenarios

Examples:

• Nightly export of transactional data to a data warehouse
• Scheduled import of price lists or reference data

5. File-Based Integration

File-based integration involves systems exchanging data using files such as CSV, XML, or JSON, typically transferred via secure mechanisms like SFTP or shared storage. This pattern is often used when integrating with legacy or third-party systems that do not support modern APIs.

While file-based integration is relatively simple and widely supported, it tends to introduce higher latency and weaker validation, as errors are often detected only after file processing. It is best suited to low-frequency, non-time-critical scenarios such as bulk data imports or exports. It should generally be avoided in favour of other integration patterns.

When to use:

• Legacy systems with limited API capability
• Batch-oriented integrations

Examples:

• Importing contacts via CSV
• Exporting data to SFTP for external partners

Integration Technologies

Power Platform Integration Technologies

Power Platform provides low-code integration technologies that allow Dynamics 365 to integrate with other systems quickly, consistently, and with minimal custom development. Central to this capability is Power Automate, which enables lightweight integrations to be built. Power Automate uses pre-built standard connectors for Microsoft services (such as Dynamics 365, Dataverse, SharePoint, and Outlook) and many third‑party SaaS platforms, allowing integrations to be created by configuring actions and triggers rather than writing bespoke code.

For systems that do not have an existing connector, custom connectors can be created to expose external APIs in a reusable and governed way. This allows low-code flows to interact with bespoke or legacy services while still enforcing consistency, security, and authentication standards. Power Platform integration technologies are best suited to low complexity scenarios, such as event-driven workflows, simple data synchronisation, approvals, and notifications. They are not suitable for high-volume processing, complex integrations, or advanced transformation scenarios where Azure integration services are better suited.

• Triggering processes on record CRUD operations
• Simple synchronisation with Microsoft and third-party SaaS applications
• Rapid delivery with minimal infrastructure management
• Custom Connectors allow external APIs to be exposed consistently to Dynamics 365 and Power Apps

Azure Integration Technologies

Azure provides enterprise-grade integration technologies that complement Dynamics 365 by supporting high-volume, complex, and scalable integration scenarios. Services such as Azure Logic Apps, Azure Functions, Azure Service Bus, and Azure Event Grid are commonly used to implement asynchronous, event-driven integrations. These services enable robust message handling, custom transformations, and reliable communication between Dynamics 365 and other internal or external systems, as well as functionality to better handle failures and reprocessing events.

Azure integration technologies are best suited to code-first approaches where greater control, performance, and extensibility are required. They support advanced patterns such as publish and subscribe, guaranteed delivery, and long-running processes, making them ideal for complex environments with multiple systems and complex dependencies. They require more technical expertise and operational management than Power Platform solutions, but Azure services provide the resilience, scalability, and flexibility needed for business critical Dynamics 365 integrations.

Azure Logic Apps – A low-code integration and workflow application for orchestrating multi-step, long-running integrations between Dynamics 365 and other systems.

Azure Functions – A serverless compute service used to run pro-code bespoke logic, such as data transformation or validation, in response to events or API calls.

Azure Service Bus – A reliable messaging service using queues and topics to support asynchronous, decoupled, and resilient integrations with Dynamics 365 and other systems.

Azure Event Grid – A lightweight event routing service used to publish and distribute events from Dynamics 365 and other systems to multiple subscribers in near real time.

Integration Technology Decision Matrix

This decision matrix provides a high-level comparison of integration technologies available for Dynamics 365, helping choose the most appropriate option based on integration style, complexity, scalability, and delivery approach.

Capability / Requirement	Power Automate	Azure Logic Apps	Azure Functions	Azure Service Bus	Azure Event Grid
Integration style	Low‑code workflows	Orchestrated workflows	Code‑based processing	Messaging	Event routing
Best suited for	Lightweight event driven integrations	Enterprise orchestration	Custom logic and transformations	Reliable async integration	Publish and subscribe scenarios
Low-code support	Yes	Yes	No	No	No
Built-in connectors	Microsoft and third-party	Microsoft and third-party	None	None	None
Asynchronous processing	Yes	Yes	Yes	Yes	Yes
High-volume handling	Limited	Moderate	Strong	Strong	Strong
Guaranteed delivery	Limited	Yes	Bespoke	Yes	No
Typical use cases	Notifications, approvals, simple events	Complex business processes	Performing complex validation or enrichment	Delivering events reliably to another application	Business event broadcasting

Summary

Dynamics 365 supports a wide range of integration patterns from simple synchronous APIs to fully event-driven architectures. Power Platform enables lightweight low-code integration, while Azure services provide enterprise-grade scalability and resilience.