Near Real-Time from Dataverse: Azure Service Bus Is the Bridge You Actually Need
Queues, topics, subscriptions, and the three ways to consume them
For years, the default answer to almost every near real-time integration question in the Power Platform was reassuringly simple: build a flow. When the record changes, the flow fires, the connector runs, the external system updates. It works. Until it does not.
Until the volume spikes and the flow times out. Until the external service is temporarily unavailable and the flow retries until it exhausts its capacity. Until you realise that synchronous point-to-point integration is not an architecture, it is a hope.
The better question is not whether your integration should be near real-time. It is whether the integration layer can absorb failure without taking the business process down with it.
Azure Service Bus is the answer. It sits between Dataverse and your external systems as a durable, reliable message broker that decouples producers from consumers, levels load, and gives you first-class retry and dead-letter semantics. Microsoft even provides a native Dataverse integration for Service Bus, so the plumbing is already there.
This article explains the core concepts, the tooling, the consumption patterns, and the decision framework for choosing between Logic Apps, Azure Functions, and Custom APIs when you need to process those messages.
Queues versus topics: the first architectural decision
Service Bus offers two fundamental messaging patterns. The choice between them is not cosmetic, it defines how your integration handles scale, failure, and multiple downstream consumers.
Queues: point-to-point with competing consumers
Queues are the simpler pattern. A producer sends a message to a queue. One consumer receives it. If multiple consumers are listening, they compete for messages, and each message is delivered to exactly one consumer.
This is the right pattern when you need work distribution. You have ten Azure Functions instances processing messages from a queue, and each message is handled once. No duplicates, no gaps.
Queues store messages durably. They are triple-replicated across availability zones when the namespace is zone-enabled. Messages are ordered and timestamped on arrival. The consumer pulls messages when it is ready, not when the producer pushes them.
For Dataverse integration, a queue is the natural choice for event-driven patterns. When a record is created or updated, a message is published to a queue. The consumer processes it at its own pace, respecting Dataverse API limits and retrying on failure.
Topics: publish-subscribe with filtering
Topics are the more flexible pattern. A producer sends a message to a topic. Subscribers receive copies of messages that match their subscription rules. Each subscriber gets its own queue of messages.
This is the right pattern when multiple downstream systems need the same data. You have a CRM system, an analytics system, and a notification service that all need to react to the same Dataverse event. With a topic, you publish once and each subscriber gets its own copy.
Subscription rules add power. Each subscription can define a filter (which messages to receive) and an action (how to modify the message before delivery). For example, one subscription might only receive messages where the record type is "account", while another receives all messages.
For Dataverse integration, topics are useful when you have multiple integration flows that need to react to the same events without duplicating the publishing logic.
Service Bus Explorer: the tool you actually need
Service Bus Explorer is a free, open-source tool by Paolo Salvatori that gives you full visibility and control over your Service Bus namespace. It is the Swiss army knife for Service Bus administration and debugging.
With Service Bus Explorer, you can:
- Inspect queues, topics, and subscriptions in real time
- Peek at messages without consuming them
- Send test messages to validate your integration
- View dead-lettered messages and understand why they failed
- Clear queues or topics for testing
- Export messages for analysis
- View namespace metrics and throughput
For anyone building Dataverse integrations with Service Bus, Service Bus Explorer is essential. It is the difference between guessing why a message failed and knowing exactly what happened.
Consuming Service Bus messages: three approaches
Now comes the practical question: how do you consume those messages from Service Bus and write them to Dataverse? Three approaches, each with trade-offs.
Logic Apps: the low-code option
Logic Apps has native integration with Service Bus. You can use the Service Bus connector to trigger a Logic App when a message arrives in a queue or topic subscription. The Logic App then processes the message and writes to Dataverse using the Dataverse connector.
This is the simplest option for Power Platform teams. The Logic App designer handles authentication, message deserialization, and error handling. You add the Dataverse connector actions, define the mapping, and deploy.
The trade-off is performance. Logic Apps adds overhead: state management, connector authentication, and the visual designer's abstraction layer. For moderate volumes, this is fine. For high-throughput scenarios, you need something faster.
Azure Functions: the performance option
Azure Functions has native Service Bus triggers. You write code in C#, Python, JavaScript, or any supported language, and the function is invoked when a message arrives. The function processes the message and writes to Dataverse using the Web API or SDK.
This is the fastest option. Azure Functions with a Service Bus trigger can process messages with minimal latency. You control the batching, retry logic, and error handling. For Dataverse integration, you can batch writes, respect API limits, and implement exponential back-off.
The trade-off is complexity. Azure Functions is a code deployment. It requires a development pipeline, version control, testing, and deployment automation. It is not something a Power Platform maker maintains.
Custom APIs: the control option
A custom API can consume Service Bus messages and write to Dataverse. This is typically built as an Azure Function with an HTTP trigger that acts as a custom API endpoint, or as an API Management service that fronts a backend service.
This is the most flexible option. You control every aspect: authentication, message format, error handling, and the Dataverse write pattern. For Dataverse integration, you can implement custom validation, transformation, and business rules that Logic Apps cannot express.
The trade-off is the highest complexity. A custom API is a full integration service. It requires a development pipeline, monitoring, logging, and maintenance. For Dataverse integration, you also need to handle authentication, rate limiting, and error handling that the platform does not provide.
Production pitfalls
Every approach has traps. Here are the ones that matter most.
Message ordering
Service Bus does not guarantee message ordering across multiple consumers. If your integration requires strict ordering, use sessions. Sessions guarantee first-in-first-out (FIFO) delivery within a session, but they add complexity and reduce throughput.
Dead-lettered messages
When a message fails processing, it is moved to the dead-letter queue. If you do not monitor the dead-letter queue, failed messages accumulate silently. Set up monitoring and alerting for dead-lettered messages.
Message size limits
Service Bus has a maximum message size (256 KB for Standard, 100 MB for Premium). For Dataverse integration, this is rarely an issue. If you are sending large payloads, consider splitting them into multiple messages or using a different storage mechanism, like Azure Blob Storage.
Namespace limits
Service Bus namespaces have throughput limits. For Standard namespaces, the limit is 10,000 messages per second. For Premium namespaces, the limit is higher and configurable. Monitor your namespace metrics and plan for scale.
A practical decision framework
When you face a near real-time integration requirement, ask these questions in order.
Is the integration event-driven? If yes, Service Bus is the right choice. If no, consider a different pattern.
Do you need multiple consumers? If yes, use a topic with subscriptions. If no, use a queue.
Who will maintain this? Power Platform makers: Logic Apps. Azure/IT team: Logic Apps or Azure Functions. Development team: Azure Functions or custom API.
Is throughput critical? If yes, Azure Functions with a Service Bus trigger. If no, Logic Apps is simpler and sufficient.
Do you need custom validation or transformation? If yes, Azure Functions or custom API. If no, Logic Apps is sufficient.
The better question
The better question is not whether you should use Service Bus. You should. The better question is which layer should own the message processing, the transformation logic, and the error handling.
Logic Apps for Power Platform teams that need a simple, maintainable integration. Azure Functions for teams that need performance and control. Custom APIs for teams that need full control over the integration contract.
The integration is not a feature. It is a boundary, and boundaries need maintenance.
Sources and further reading
- Introduction to Azure Service Bus Messaging - Microsoft Learn. Documents the Service Bus service, its plans, and its integration capabilities.
- Service Bus queues, topics, and subscriptions - Microsoft Learn. Documents the queue and topic patterns, including filters and actions.
- Azure Service Bus connector for Power Platform - Microsoft Learn. Documents the native Service Bus connector for Power Platform and Logic Apps.
- Azure Functions Service Bus trigger bindings - Microsoft Learn. Documents how to use Service Bus triggers with Azure Functions.
- Service Bus Explorer - Open source. The Swiss army knife for Service Bus administration and debugging.
- Azure Service Bus Integration for Dataverse - Microsoft Learn. Documents the native Dataverse-Azure Service Bus integration patterns.
Research note: Using Microsoft Learn MCP is encouraged for Microsoft topics. Prefer local search for private or project-specific material, and use RivalSearchMCP or Brave Search MCP for broader discovery before verifying material claims against primary sources.
