Azure Service Bus integration with Dataverse

Service Bus integration is one of Dataverse's most enterprise-friendly outbound integration mechanisms. When Dataverse changes a record, it publishes a message to an Azure Service Bus queue or topic; downstream consumers process the message at their own pace, with durable retention and built-in retry. For high-volume, async, decoupled integrations, this is the right pattern.

The architecture.

1. A Dataverse record changes (Create, Update, Delete, etc.).
2. A configured Service endpoint of type Service Bus catches the event.
3. Dataverse serialises the relevant record context (target entity, attribute changes, before/after images) into a Service Bus message.
4. The message is published to a Service Bus queue or topic.
5. One or more downstream consumers — Azure Functions, custom code in a VM, Logic Apps, third-party services — read from the queue/topic and process.

Queues vs topics.

• Queue — point-to-point: one publisher, one consumer (or one consumer at a time). The consumer reads and the message is removed.
• Topic — publisher with multiple subscribers: each subscriber gets its own copy. Useful when several systems should be notified of the same change.

Choose queue when one system handles each change. Choose topic when multiple systems care about the same change.

Registration. Service Bus integration is configured through the Plug-in Registration Tool (legacy but still functional) or through programmatic registration. The configuration includes: connection string to the Service Bus namespace, queue/topic name, message format (XML or JSON), and which Dataverse messages and entities trigger publication. Registration can be synchronous (block the Dataverse operation until the message is published) or asynchronous (queue locally and publish on the async service queue).

Asynchronous registration is overwhelmingly the right choice — synchronous Service Bus publication couples Dataverse availability to Service Bus availability.

Message format. Dataverse publishes either:

• Entity image — a snapshot of the changed record including pre-image and post-image attributes.
• Execution context — the full context (message, entity, target, user, parameters, etc.) serialised as XML/JSON.

Most consumers want the execution context for flexibility — they can determine what changed and act on it.

Consumer patterns.

• Azure Functions — serverless: trigger on queue message, scale out, process, ack. The most common pattern.
• Logic Apps — trigger on Service Bus message, orchestrate downstream steps with retry and error handling.
• Custom services — long-running consumers in App Service, AKS, VMs.
• Third-party SaaS — many SaaS products consume Service Bus messages natively.

Resilience. Service Bus is the answer when consumers cannot be assumed always-on. Messages persist in the queue for up to a configurable retention window (defaults to 14 days, max much longer). Failed processing returns the message to the queue (or to a dead-letter queue (DLQ) after configurable retry limits) for later investigation. Dataverse fire-and-forgets; the queue is the durability layer.

Throughput. Service Bus standard tier handles hundreds of messages per second; premium handles many thousands. Plan capacity against expected Dataverse change volume.

Vs Event Grid / Webhooks.

• Service Bus — durable, ordered, point-to-point or pub/sub at moderate scale. The right choice for transactional integration.
• Event Grid — high-volume fan-out at scale, lightweight. The right choice for many subscribers wanting near-real-time events.
• Webhooks — direct HTTP POST, simpler, no retry beyond a few attempts. The right choice for low-volume real-time and tolerant consumers.

For Dynamics 365 enterprise integrations with serious volume and reliability requirements, Service Bus is the canonical default.