Event-driven integration with Azure Service Bus

The hardest part of most Power Platform projects isn’t building the app — it’s making it talk to other systems reliably. Direct, point-to-point integrations look simple at first and become brittle fast: when one side is down, the other fails; when volume spikes, things fall over; when a message is malformed, the whole chain stops. An event-driven design with Azure Service Bus avoids that by decoupling the systems that produce events from the systems that handle them.

This is the difference between an integration that works in a demo and one that survives in production, month after month, under real load and real failure.

Queues, topics and decoupling

Service Bus is a message broker. There are two core building blocks:

• A queue holds messages until a consumer is ready to process them. One producer, one logical consumer, with the broker in between.
• A topic fans a message out to multiple subscriptions, so several independent consumers can each react to the same event.

Either way, the producer’s job ends when the message is safely enqueued — it doesn’t wait for, or depend on, the consumer. That decoupling is what makes the whole system resilient: components can scale, fail and recover independently. If the consumer is down for ten minutes, messages simply wait; nothing is lost, and processing resumes when it recovers.

Reliability is built in

Service Bus gives you the mechanics of reliable delivery out of the box:

• Retries handle transient failures automatically.
• A dead-letter queue captures messages that repeatedly fail to process, so they’re set aside for investigation instead of silently disappearing or blocking the queue.
• Sessions let you process related messages in strict order when ordering matters.

These are exactly the features that are painful to build yourself and essential to get right, which is why leaning on the broker rather than hand-rolling them is almost always the better choice.

A worked example: a file-processing pipeline

A common shape we build is a serverless pipeline that imports structured files into Dataverse. It ties together Blob Storage, Service Bus and Azure Functions:

1. Files land in Blob Storage, organised into containers for raw, processing, archive and failed files.
2. A Blob trigger Function fires when a file arrives and publishes the file’s metadata as a message to a Service Bus topic.
3. A second Service Bus-triggered Function consumes that message and runs the import.

Upload and processing are fully decoupled, so a sudden burst of files never overwhelms the system — they queue up and are processed at a sustainable rate.

Configuration over code

The processing Function is deliberately generic. Rather than hard-coding how to handle each file type, it’s driven by a small configuration — effectively a domain-specific language — that describes:

• how to parse the file (delimiters, headers, which sheet, which rows to skip),
• which Dataverse table to target and whether to create, update or upsert,
• how to map and transform each field,
• what validation and duplicate-detection to apply,
• and what to do afterwards on success or failure.

Because the rules live in configuration rather than code, supporting a new file format is a configuration change, not a deployment. Non-developers can define new imports, and the engine itself stays untouched and well-tested.

The principles that make it hold up

Three principles do the heavy lifting across any integration like this:

• Loose coupling. Each component connects only through well-defined messages, so it can be changed, scaled or replaced on its own without breaking the others.
• Configuration over code. Business rules live outside the engine, so the system adapts to new requirements without redeployment.
• Idempotent processing. Operations are safe to repeat, which is essential when a message might be delivered more than once. Processing the same file twice must not create duplicate records.

Observability and operations

End-to-end tracing through Azure Monitor and Application Insights ties the whole flow together — from the file arriving in storage to the record landing in Dataverse — so you can answer “what happened to this file?” in seconds rather than guessing. Every message carries correlation information, every stage logs its outcome, and failures land in the dead-letter queue with enough context to act on.

The result is an integration you can actually operate: resilient under load, transparent when something goes wrong, and easy to extend as new sources and formats appear. That operability is the real payoff of an event-driven design — not just that it works, but that when it doesn’t, you know immediately and can fix it fast.

When to reach for this

Not every integration needs a message broker; a simple, low-volume sync might be fine as a direct call. But the moment you care about reliability under load, independent scaling, guaranteed delivery, or decoupling systems that shouldn’t depend on each other’s uptime, event-driven integration with Service Bus is the pattern that will still be standing a year later.