Why I stopped letting external systems talk directly to Power Platform.
Direct integrations feel simple. They work — until they don't. Here's the inbound pattern I now reach for every time, and the five problems it quietly eliminates before they become your 2am incident.
You've built the integration. An external system — maybe a third-party platform, a legacy database, an external API — pushes data directly into Power Platform. A flow fires, a record gets created in Dataverse. It works in testing. It works in UAT. You go live.
Three weeks later, you're looking at duplicate contacts, missing records, and a business stakeholder asking why the same customer appears four times with slightly different details.
This is the pattern I use instead — and why I won't go back.
The problems
Five failure modes that don't show up in testing.
The pattern
Inbound via Azure Service Bus.
Stop letting external systems talk to Power Platform directly. They talk to a queue. Your processor talks to Power Platform. The queue is the buffer, the safety net, and the audit trail.
Breaking it down
What each layer actually does for you.
- External systems publish and forget. They don't need to know if Dataverse is throttled or your flow is backed up.
- Messages are durable. If nothing consumes them for an hour, they're still there waiting.
- Built-in retry policy means transient failures are handled automatically, with configurable backoff.
- Dead-letter queue captures anything that exhausts retries — you get visibility, not silence.
- Before anything touches Dataverse, the processor validates the payload, checks required fields, and rejects what doesn't belong.
- Deduplication happens here — check against existing records by email, external ID, or composite key before you write.
- Transformation lives here too — normalise formats, resolve lookups, enrich with data from other systems.
- Azure Function gives you full control and language choice. Power Automate works for simpler flows but hits limits faster under load.
- By the time a record reaches Dataverse, it has been validated, deduplicated, and transformed. Your CRM stays clean.
- API limits are protected by the Service Bus buffer — high-volume spikes are absorbed upstream, not thrown at Dataverse directly.
- The Service Bus audit trail means you can replay or investigate any message that ever entered the pipeline.
Applicability
When does this pattern make sense?
Not every integration needs this. A simple internal Power Automate flow triggered by a Dataverse change doesn't need a Service Bus in front of it. But reach for this pattern whenever you see any of the following.
What this actually changes.
The most common objection is that it feels like overkill. More infrastructure, more moving parts, more to understand.
That's true in a greenfield environment with one integration and low volumes. But the moment you're running a Dynamics 365 environment that an organisation depends on — with customer records, transactional data, regulated information — the risk profile changes completely.
A Service Bus queue costs almost nothing to run at most integration volumes. What it buys you is the ability to sleep without worrying that a network blip at 3am has silently dropped fifty records with no way to recover them.
"The outbound journey — when Dataverse or Power Automate needs to push data out to an external system via a processor."
Same philosophy, different flow, different failure modes to protect against.
Read Part 2 →