The pattern is the easy part. The limits decide it.
Microsoft publishes six integration patterns for Dynamics 365 finance and operations apps, and the right one depends on latency and coupling rather than preference. What decides most projects is not the pattern but the limits underneath it: service protection ceilings enforced per user per server, OData throughput measured in records per hour against a batch API two orders of magnitude faster, business events whose delivery order is explicitly not guaranteed, and a recurring-integrations queue that re-serves an unacknowledged message every thirty minutes. Design for those four and the integration holds. Design around them and it fails quietly, months later, under load.
Where these projects actually fail
Service protection limits
OData throughput
Business events have no ordering guarantee
Recurring integrations re-serve messages
Each one is Microsoft’s published behaviour, with the write-up linked below.
Why an optimization company writes about integration limits
We do not sell integration as a service line. But every optimizer and every agent has the same first problem: read the system of record live, compute something the ERP never calculated, and write the result back without touching core logic or breaking the upgrade path.
That problem is where these engagements actually fail, and it fails late — under production load, on the pattern that tested fine. So the limits below are not background reading. They are the constraints every decision layer we build has to live inside.
Six patterns, and what each is built for
Microsoft's integration overview for finance and operations apps opens by listing six available patterns. The comparison that matters is latency against coupling — how fresh the data is, and how much breaks when either side changes.
Two of the six are batch-shaped and two are event-shaped, which is the split most design reviews actually need. The full comparison, with what each costs, is in the article linked beneath this section.
All six compared, with what each costs →The four limits that decide the design
Each of these is Microsoft's published behaviour, not folklore. Each has a full write-up behind it.
Service protection limits
Three limits are enforced per user per server, and the finance and operations endpoints answer differently from the Dataverse side. The trap is the response to hitting one: a naive retry loop increases the request rate against a limiter that is already throttling you, so the integration degrades faster the harder it tries.
The full write-up →OData throughput
Microsoft's own sizing examples put OData at a peak measured in records per hour, and put the batch data API two orders of magnitude above it. Choosing OData for a bulk job is not a slow choice, it is the wrong instrument. Four specific OData behaviours also make a working integration slower or quietly wrong.
The full write-up →Business events have no ordering guarantee
Microsoft states it under a heading called Limitations: the order in which finance and operations emits business events is not guaranteed to be the order in which they are delivered. The control number is a dedupe key, not a sequence. Consumers have to be idempotent, derive state from the record rather than from the event order, and reconcile against the ERP rather than against the stream.
The full write-up →Recurring integrations re-serve messages
A duplicated document is a redelivery, not a lost message. An unacknowledged message becomes available to dequeue again every thirty minutes until it is acknowledged, and the acknowledgement must echo the dequeue response body. Three common implementation mistakes break that contract, and each produces duplicates that look like a data problem.
The full write-up →The boundary we hold, whatever the pattern
The decision layer reads the system of record as it is, through supported surfaces. A nightly extract makes yesterday's answer, and a planner who catches it once stops trusting the system.
The app returns its own output to its own fields. It does not rewrite records it did not author, which is what keeps the upgrade path and the implementation partner's support intact.
Money or stock moving is proposed and prepared, then approved by someone. That design is what gets an IT director to say yes, and it is stronger than promising autonomy.
OData data entities, custom services and business events, with an Entra app registration mapped to a service role. Reaching around them into the database is what breaks the next update.
Dynamics 365 integration, answered plainly
- Does Business Central have an API?
- Yes — Business Central exposes REST APIs and OData endpoints, and the 2026 wave 1 release adds a built-in MCP server so an agent can call them as tools. Finance and Supply Chain Management is a different product with a different surface: OData data entities, custom services and business events. The difference between the two is most of the expertise in these engagements.
- What are the Dynamics 365 integration patterns?
- Microsoft names six for finance and operations apps. Two are batch-shaped, two are event-shaped, and the choice is decided by latency and coupling rather than preference — how fresh the data has to be, and how much breaks when either side changes.
- Why is our OData integration slow?
- Often because it is the wrong instrument for the job. Microsoft's published sizing examples put OData at a peak measured in records per hour and the batch data API two orders of magnitude above it. Four further OData behaviours can make a working integration slower or quietly wrong.
- Why are we getting duplicate documents from a recurring integration?
- It is a redelivery, not a lost message. An unacknowledged message becomes available to dequeue again every thirty minutes until acknowledged, and the acknowledgement has to echo the dequeue response body. Duplicates almost always trace to that contract being broken rather than to the data.
- Can we rely on the order business events arrive in?
- No, and Microsoft says so under a heading called Limitations. The emission order is not guaranteed to be the delivery order, and the control number is a dedupe key rather than a sequence. Build idempotent consumers that derive state from the record.
- Do you sell integration services?
- No. We build optimization apps and the decision layer beside the ERP, and every one of them has to read and write the ERP safely to work at all. This page is that groundwork, not a service line.