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. In practice, most of these patterns end up wired to one of a small set of common third-party SaaS products — e-signature (DocuSign and Adobe Sign), marketing (HubSpot, Mailchimp and SendGrid), payments (Stripe and PayPal), and communications (Twilio) — each with its own guide covering the specific connector or webhook shape.

Where to go next

Each pattern has a deeper guide: webhooks vs events, Service Bus integration, plug-ins vs Power Automate, and virtual tables. The two cross-cutting disciplines are idempotency and polling vs push. At the architecture level above these individual patterns sit event-driven architecture, anti-corruption layers for protecting Dynamics 365 from an external system's model leaking in, and the protocol choice itself in SOAP vs REST vs GraphQL.