Introduction
Integrations can account for a substantial share of the work in a Dynamics 365 Finance & Operations implementation, particularly when F&O must exchange data with CRM, e-commerce, banking, warehouse, logistics, or legacy systems. They are also a frequent source of delays when volume, security, data dependencies, and failure handling are addressed too late. That is why works best as part of solution design, not as a separate workstream added later.
In simple terms, APIs are the controlled channels through which applications exchange information and request actions from one another. In Dynamics 365 F&O, OData is a standard for exposing business data through APIs, allowing other applications to read or write data such as customers, products, orders, and invoices. The distinction matters because choosing how those exchanges are designed can directly affect performance, security, reliability, and implementation cost.
The good news is that most integration problems are architectural rather than mysterious. The right pattern, sensible API usage, controlled concurrency, reliable validation, and proper operational monitoring can keep integrations dependable without making the ERP handle all workloads. Here are 10 practices to apply during an F&O implementation to improve performance, reduce support effort, and protect your investment.
1. Choose the integration pattern before choosing the API
The first decision should be how the data needs to move, rather than which endpoint to call.
Dynamics 365 F&O supports several integration approaches, including OData, custom services, batch data integrations, and event-based patterns. Microsoft recommends selecting the approach based on the scenario rather than treating OData as the universal answer.
Consider:
- Real-time APIs: orders, pricing, availability, or other transactions requiring an immediate response.
- Batch processing: large data transfers, migrations, and scheduled updates.
- Event-driven integration: reacting to inventory, shipment, posting, or other business events.
- Dataverse and dual-write: scenarios connecting F&O with Dataverse-based applications and Power Platform.
Large volumes should not be forced through real-time APIs simply because they are available. That is a good way to turn an integration into a queue with a very expensive waiting room. Choose the pattern based on business needs, volume, and risk.
2. Secure every integration as a production system
An integration should maintain the same security discipline as any other enterprise application.
A robust design should include:
- A dedicated identity for each integration.
- Least-privilege access to the required resources.
- Centrally managed credentials and secrets.
- Controlled access through an API gateway where appropriate.
- Audit trails for significant transactions and administrative actions.
- Defined procedures for failed or reprocessed messages.
This is especially important when integrations can create or modify financial or operational records. Security should therefore be part of the architecture, not something added before go-live.
3. Design around platform limits
F&O applies service protection and resource-based limits to help preserve system responsiveness and availability. Therefore, high-volume integrations must account for throttling rather than treat it as an unexpected error.
For business leaders, the practical implications are simple:
- Group related operations where appropriate.
- Page large data reads.
- Schedule heavy workloads outside peak operating periods.
- Separate integration workloads from interactive user activity.
- Monitor throttling and response times.
The objective is to prevent an integration workload from competing with finance, supply chain, or operations users for the same platform resources.
4. Make transactions safe to retry
Networks fail. Services restart. Requests time out. A transaction that fails midway should not leave the business wondering whether it actually happened.
Design integrations around idempotency, meaning that repeating the same request does not create another business transaction.
Useful controls include:
- A unique external reference or idempotency key.
- Correlation IDs for tracing individual transactions.
- Retry logic for transient failures.
- A queue for messages that cannot be processed automatically.
- Alerts when repeated failures require human intervention.
Microsoft also documents retry handling for throttled requests, including the use of the Retry-After interval returned with applicable API errors.
5. Respect transaction dependencies
ERP transactions often follow a specific sequence. For example, a sales order has a header and lines, and the lines depend on the order being created first.
A typical sequence is:
Sales Order Header → Capture Order Number → Sales Order Lines
Treat these as discrete operations and carry a correlation ID through the middleware and F&O calls. If a line fails, the integration should be able to identify the order, the specific line, and the reason for the failure. This approach makes recovery considerably easier than attempting to diagnose a collection of unrelated API calls.
6. Validate master data before calling F&O
Many integration failures have little to do with the API itself. The customer, item, unit of measure, warehouse, address, or financial dimension may be invalid.
Where practical, middleware should validate key reference data before submitting the transaction.
For example:
- Is the customer valid?
- Is the item active?
- Is the unit of measure recognized?
- Is the warehouse valid?
- Are required financial dimensions present?
Frequently accessed reference data can also be cached and periodically refreshed, reducing unnecessary calls to F&O. This creates a useful separation: middleware handles predictable data problems, while F&O remains responsible for enforcing its business rules.
7. Use batching and paging for higher throughput
OData supports batch requests and server-driven paging, with a maximum page size of 10,000.
These capabilities matter when integration volumes rise.
Instead of sending thousands of individual requests:
- Group related operations where appropriate.
- Page large reads rather than requesting everything at once.
- Avoid unnecessarily retrieving fields that the integration does not require.
- Cache metadata and other information that does not change frequently.
- Measure throughput rather than assuming that more parallel requests means faster processing.
The right balance depends on the entity, transaction patterns, environment, and workload.
Higher throughput comes from controlled processing, not from simply more requests.
8. Control concurrency for sensitive transactions
Parallel processing can increase throughput, but unrestricted concurrency can also create contention.
For high-volume transactions involving sensitive entities, integrations should be tested to determine the appropriate concurrency level. This is particularly important for sales orders and related entities where large bursts of activity can compete for the same resources.
A better approach is to:
- Pace requests rather than release thousands simultaneously.
- Establish tested concurrency limits.
- Monitor throttling and processing latency.
- Adjust throughput according to observed platform behavior.
This becomes especially valuable during order spikes, promotions, month-end activity, or other predictable periods of high demand.
Concurrency should be engineered, tested, and governed rather than left to chance.
9. Make every integration observable
When an integration fails, the first question should be “What happened?”, not “Which developer built this three years ago?”
Each integration should provide a traceable operational record that includes, where appropriate:
- Unique transaction or correlation ID
- Source and destination
- Processing status
- Error details
- Retry history
- Processing time
- Records affected
Operational dashboards can then monitor:
- Error rates
- API latency
- Throttling events
- Queue depth
- Failed transactions
Runbooks should accompany these dashboards, documenting common errors and the steps to investigate and resolve them. Agree early who owns this monitoring after go-live, whether that is an internal team or an .
10. Separate integration workloads from interactive users
F&O is the system of record for critical financial and operational processes. Its capacity should therefore be protected from workloads that do not require immediate processing.
A sensible architecture separates:
Interactive users | Real-time integrations | Batch workloads
For example, a large import can be processed through the appropriate batch or Data Management Framework mechanisms during a suitable operating window, while a customer order requiring an immediate response can be handled with an appropriate real-time integration pattern.
This separation helps protect the user experience, particularly during month-end close and peak operational periods, and provides a more controlled environment for high-volume processing.
Building integrations that remain supportable
The strongest F&O integration designs follow a repeatable sequence:
- Discover business processes, systems, data, and volumes.
- Select the appropriate integration pattern.
- Design identity, security, data ownership, and failure handling.
- Build with defined performance and transaction boundaries.
- Test normal loads, peak loads, failures, retries, and recovery.
- Operate with monitoring, runbooks, ownership, and service levels.
LevelShift applies this discipline within its broader expertise, bringing integration decisions into the context of the wider ERP solution. This helps teams account for dependencies among business processes, configuration, data, security, and integrations early in implementation, while ensuring the resulting solution is tested and supported as a cohesive environment. For organizations implementing F&O, this broader perspective can help reduce integration-related surprises and provide greater confidence in the solution before it reaches production.
LevelShift offers a focused that puts this approach into practice before development begins. The assessment produces an integration catalog, pattern map, and risk register, helping teams set priorities, identify potential risks, and make informed integration decisions as part of the broader F&O implementation.
Conclusion
Good integrations should make business processes more dependable, not create another operational system for IT to manage. The principles are relatively straightforward: choose the right pattern, protect the platform, validate data, control concurrency, make transactions safe to retry, and provide enough observability to resolve failures quickly.
The result is more than a collection of working APIs. It is an integration architecture that can support faster transaction cycles, fewer manual reconciliations, protected ERP performance, and a lower long-term support burden. With the right design decisions made early, F&O integrations can remain a useful part of the ERP architecture rather than a recurring source of trouble.
Planning a Dynamics 365 F&O implementation or looking to improve your existing integrations? LevelShift can help you build a secure and reliable Dynamics 365 solution aligned with your business goals. to discuss your integration requirements and explore how our expertise can support your implementation journey.
FAQs
- Is OData the best integration option for Dynamics 365 F&O?
Not always. OData is best suited for synchronous data operations, whereas batch, event-driven, custom service, or Dataverse patterns may be better suited to other scenarios. - When should an organization avoid real-time APIs?
For very large data transfers. Batch or data-management methods are generally better suited to high-volume workloads. - How can integrations prevent duplicate transactions?
Use unique references or idempotency keys, correlation IDs, retry logic, and failed-message queues. - Why does API throttling matter to business users?
Poorly controlled traffic can increase processing times and affect interactive F&O users. - What should be tested before an F&O integration goes live?
Test normal and peak loads, failures, retries, throttling, recovery, and end-to-end reconciliation.