Most Dynamics 365 integration projects I am asked to rescue have the same root cause. Someone picked the wrong pattern at the start. They chose real time when batch would have done. They chose direct database calls when an API would have been safer. They chose a middleware platform because a sales rep sold it to them, not because it actually suited the problem. The wrong pattern will haunt your project for years, so getting this decision right at the start is worth hours of careful thinking.
Dynamics 365 integration is a topic where the official documentation tells you what is possible but almost never tells you what is a good idea. This post is the opposite. Here are the patterns I actually use, why I use them and when I walk away from them.
Start with the question nobody asks
Before picking any pattern, answer this honestly. Does this actually need to be real time? In my experience about eighty percent of integrations that were built as real time should have been hourly or nightly batches. Real time integration is expensive to build, fragile to maintain and almost always overkill for the actual business need.
The classic example is syncing customers between your finance system and Dynamics 365. The sales team will tell you it must be real time. Ask them what actually goes wrong if a new customer takes thirty minutes to appear. Usually the answer is nothing. A fifteen minute scheduled sync would save tens of thousands of pounds and reduce support calls by ninety percent.
Real time integration is worth the cost only when the business process genuinely cannot tolerate a delay. Stock levels during an active sale. Payment authorisation. Credit checks at point of order. Beyond that, you are almost certainly overengineering.
The four patterns I actually use
There are dozens of integration patterns in the textbooks. In practice I find myself reaching for four again and again. Everything else is a variation.
Scheduled batch with Azure Data Factory or Logic Apps
This is my default for any integration where latency beyond a few minutes is acceptable. Azure Data Factory for anything data heavy. Logic Apps for anything with more complex branching or approval steps. Both play nicely with Dataverse and both are much cheaper to run than people realise.
The big advantage of batch is that it is idempotent by design if you build it properly. If it fails at three in the morning, it just runs again at four. No paging a developer. No lost data. Compare that to a real time webhook that silently dropped a message six hours ago and nobody noticed.
Event driven with Service Bus
When you do need something close to real time and you need it to be reliable, Azure Service Bus is the answer. Plugins in Dynamics 365 write messages to a queue. A consumer on the other side picks them up, processes them and acknowledges. If the consumer is down, messages pile up in the queue until it comes back. Nothing is lost.
This is the pattern I use for any integration where losing a message would be a problem. Order submission to ERP. Invoice generation. Anything finance touches. The upfront cost is higher than a direct API call but the operational cost over five years is a fraction because you are not woken up at night by failed syncs.
Virtual tables for read only data
Virtual tables are one of the most underused features of the platform. If you need data from another system to appear inside Dynamics 365 but you do not actually need to store it, a virtual table is almost always the right answer. No syncing. No storage costs. No stale data.
I use these for things like warehouse stock levels, courier tracking, external pricing feeds. The user sees the data natively in the D365 interface but it is being fetched live from the source system every time. It feels like magic the first time you set one up properly.
Power Automate for low volume human processes
Not every integration needs to be an engineered solution. If the process is low volume, involves a human decision somewhere, or is going to be changed in six months anyway, use Power Automate. A flow that runs fifty times a day and is easy to modify is worth more than an elegant Azure Function that nobody understands.
The mistake people make with Power Automate is trying to use it for high volume or business critical integrations. It is not designed for that. If you are pushing ten thousand records a day through a flow, you are abusing the tool. Move it to Service Bus.
The patterns I now refuse to use
Experience is mostly a list of things you have decided not to do again. Here are mine.
Direct SQL to Dataverse
People keep trying to read or write directly to the Dataverse SQL endpoint, bypassing the platform APIs. I understand the temptation. SQL is familiar. The API feels verbose. But it is a trap. You lose business logic, you lose audit history, you lose security trimming and you are one platform update away from your integration silently breaking.
If you are tempted to go around the API, stop and ask why the API is getting in the way. Usually it is a sign that the integration design is wrong, not that the API is bad.
Point to point spaghetti
Ten years ago it was normal to build a direct connection between each pair of systems. Dynamics 365 talks to finance. Dynamics 365 talks to the website. Finance talks to the website. You end up with a web of brittle connections and nobody can remember what connects to what.
Modern integrations should go through a hub. Azure Service Bus. An integration platform. Even a custom API layer. Anything that means changing one system does not require you to rewire fifteen others. This is one of the things I wish more clients understood before they spent money on a Dynamics 365 implementation that never quite worked.
Scribe, Kingsway and the graveyard of dead tools
I have lost count of the number of projects I have been called into where the integration is running on a tool that was acquired, rebranded or quietly deprecated. If you are choosing a third party integration tool, do serious due diligence on who owns it, what the pricing looks like in three years, and whether you can export your mappings if the vendor disappears. The Azure native stack is boring but it is not going anywhere.
The unglamorous stuff that matters more than the pattern
Choosing the right pattern is only part of the job. The things that actually determine whether an integration works in production are the unglamorous ones.
Proper error handling with alerting. Dead letter queues that get checked. Retry logic that is not infinite. Logging that actually tells you what went wrong. A runbook that someone other than the original developer can follow. Monitoring that flags when throughput drops, not just when everything falls over.
I have seen technically brilliant integrations fail because nobody knew when they broke. And I have seen crude integrations run for a decade because the operational side was done properly. Spend less time picking the perfect pattern and more time making sure the one you picked will tell you when it needs attention.
When to call for help
If you are about to scope a Dynamics 365 integration and you are not sure which pattern fits, get a second opinion before you start writing code. Three hours with someone who has seen this problem a hundred times will save you three months of pain. I offer this kind of work through my Dynamics 365 consulting service and I would rather have a conversation before the integration is built than after it has gone wrong.
The patterns in this post are not exotic. They are the ones that keep turning up as the right answer on real projects. Pick the simplest one that solves your actual problem. Build the operational side properly. And do not let a sales rep talk you into a middleware platform you do not need. Do those three things and you will skip most of the integration disasters I spend my time cleaning up.
