Integration patterns for Dynamics 365 CRM

CRM-side Dynamics 365 apps share the same Dataverse-based integration surface. A small number of well-defined patterns cover essentially every integration scenario; choosing well is the difference between integrations that age gracefully and ones that need rebuilding every two years.

Pattern 1: Webhooks and Service Bus from Dataverse. Dataverse can publish row changes to:

• Webhooks — HTTP POST to a configured URL when a record is created, updated, deleted, or an action is invoked. Lightweight, but no retry beyond a few immediate attempts; the consumer must be highly available.
• Azure Service Bus — message published to a queue or topic, retained until consumed. Resilient to consumer outages. The right pattern for decoupled, durable, asynchronous notifications at scale.
• Event Grid — similar to Service Bus but lighter-weight; for fan-out to many subscribers.

These are the modern, recommended outbound patterns from Dataverse.

Pattern 2: Plug-ins. Server-side plug-ins are C# classes registered against Dataverse events that run synchronously (before/after the operation) or asynchronously (queued). Used for transactional integration — calling an external service inside the transaction and rolling back if it fails. Powerful but operationally fragile — slow external calls inside plug-ins cause timeouts. Modern best practice: keep plug-ins lean, use them for validation and triggering, and offload work to flows or Functions.

Pattern 3: Power Automate flows. Triggered by Dataverse events through the Dataverse connector. Right for business orchestration with multiple steps and human approval. Easier to maintain than plug-ins; less powerful (no transactional context with Dataverse). Use flows when the work isn't strictly part of the originating transaction.

Pattern 4: Virtual tables. Read-and-write surfaces in Dataverse that pull data from external systems on-demand without storing it. The right pattern for reading external data inside Dataverse apps without replicating — e.g. surfacing F&O customer data inside a Sales account.

Pattern 5: Pull integration via API. External system polls the Dataverse API on a schedule. Simple, but inefficient at scale and slow to react. Use when the external system can't accept pushes.

Pattern 6: Bulk via Data Factory. For bulk movement — initial loads, daily extracts, archive — Azure Data Factory or Synapse pipelines using the Dataverse connector.

Pattern 7: Synapse Link to OneLake. Continuous replication of Dataverse changes to OneLake, where analytics and downstream systems consume. The right pattern for analytics and read-only consumers at scale.

Choosing. Push beats pull at scale. Asynchronous beats synchronous when timing isn't critical. Service Bus / Event Grid beat webhooks for resilience. Flows beat plug-ins for orchestration; plug-ins beat flows for transactional concerns. Document the pattern per integration up front.