Data Integration Patterns in F&O
Master the integration landscape of Dynamics 365 Finance and Operations — synchronous, asynchronous, near-real-time patterns, and the APIs that power each one.
Data Integration Patterns in F&O
Welcome to Domain 6 — the glue that connects Dynamics 365 Finance and Operations to everything else. Every real-world deployment needs data flowing in and out — from warehouses, CRMs, e-commerce platforms, and reporting systems. This module maps out the landscape so you can pick the right tool for every job.
Think of integration patterns like postal services.
Synchronous is like handing a letter to someone face-to-face — you wait until they read it and reply. Fast for small things, but you are stuck waiting. Asynchronous is like dropping a package at the post office — you walk away and it arrives later. Great for big shipments. Near-real-time is like same-day courier — not instant, but close enough for most business needs.
F&O gives you different “postal services” (APIs) depending on how much data you are moving and how fast it needs to get there.
The Three Integration Patterns
Every integration falls into one of three timing patterns. Understanding these first makes every API decision easier.
1. Synchronous (Request-Response)
The caller sends a request and waits for the response. The operation completes in a single HTTP round-trip.
🔗 Marcus’s client call: “Anita’s e-commerce platform needed real-time inventory checks. When a customer adds an item to their cart, the website calls F&O and waits for the stock count. That is textbook synchronous — you need the answer right now, and the data volume is tiny (one item at a time).”
When to use: Interactive lookups, single-record CRUD, validations that must return immediately.
APIs that support it:
- OData endpoints —
GET /data/SalesOrderHeaders?$filter=... - Custom services — your own business logic exposed as REST/SOAP
Trade-offs: Simple to implement, but blocks the caller. Not suitable for bulk data — timeouts kill large operations.
2. Asynchronous (Fire-and-Forget with Polling)
The caller submits work and gets back a job ID. Processing happens in the background. The caller polls for status or gets notified when done.
🔗 Marcus to Tomoko: “Your nightly product catalog sync pushes 50,000 SKUs. We are not going to do that one-by-one over OData — that would take hours and time out constantly. We submit a data package, F&O processes it in the background, and your system checks back for the result.”
When to use: Bulk imports/exports, migration loads, any operation involving thousands of records.
APIs that support it:
- Data Management REST API — submit packages for import/export
- Recurring integrations — scheduled enqueue/dequeue endpoints
Trade-offs: Handles massive volumes, but introduces latency and complexity (polling, error handling for partial failures).
3. Near-Real-Time (Event-Driven)
The system pushes notifications when something happens. External systems subscribe and react.
🔗 Marcus explaining to Anita: “When a sales order is confirmed in F&O, a business event fires. Your warehouse system picks it up within seconds via Azure Service Bus. No polling, no waiting — the event finds your system.”
When to use: Cross-system workflows, notifications, triggering downstream processes.
APIs that support it:
- Business events — publish to Service Bus, Event Grid, HTTPS webhooks
- Dual-write — real-time bidirectional sync with Dataverse (covered in Module 24)
| Aspect | Synchronous | Asynchronous | Near-Real-Time |
|---|---|---|---|
| Timing | Immediate response | Background processing | Seconds to minutes |
| Volume | Low (1–100 records) | High (thousands+) | Medium (event-by-event) |
| Direction | Request → Response | Submit → Poll | Push (F&O → external) |
| Caller blocks? | Yes | No | No |
| Error handling | Inline (HTTP status) | Job status + error file | Dead-letter queues |
| Best for | Lookups, single CRUD | Bulk data movement | Triggering workflows |
| Key APIs | OData, Custom services | DM REST API, Recurring | Business events, Dual-write |
The API Landscape
Now let’s map each API to its sweet spot.
OData (REST) Endpoints
Every data entity in F&O is automatically exposed as an OData v4 endpoint. This is the default integration API for most scenarios.
GET https://your-environment.operations.dynamics.com/data/CustomersV3?$filter=CustomerAccount eq 'C001'
POST https://your-environment.operations.dynamics.com/data/SalesOrderHeadersCapabilities:
- Full CRUD —
GET,POST,PATCH,DELETE - Query options —
$filter,$select,$expand,$orderby,$top,$skip - Batch requests — group multiple operations in one HTTP call (
$batch) - Cross-company — add
?cross-company=trueordataAreaIdfilter
Limitations:
- Timeout at ~5 minutes — long operations fail
- Not designed for bulk (thousands of records = slow)
- Rate limiting applies (429 responses)
Exam tip: OData $batch for multiple operations
The exam loves testing whether you know about $batch. When you need to create a sales order header AND its lines in one call, $batch with changesets ensures atomicity. Without it, you would need separate POST calls — and if the lines fail, the header is already created (orphan record).
Custom Services
When OData’s CRUD isn’t enough — you need custom business logic — you build a custom service. This is a service class with methods, exposed via a service group.
🏗️ Vik’s take: “OData is the vending machine — you pick a standard item and it hands it back. Custom services are the full restaurant kitchen — you define the menu, the recipe, and the response. More work to build, but you can do anything.”
When to pick custom services over OData:
- You need to run complex business logic (not just read/write a table)
- The operation spans multiple entities in a single transaction
- You need a specific request/response contract
Data Management REST API
For bulk operations, the Data Management Framework (DMF) exposes a REST API. You submit a data package (a zip file of CSV/XML) and DMF processes it using the entity pipeline.
POST /data/DataManagementDefinitionGroups/Microsoft.Dynamics.DataEntities.ImportFromPackageFlow:
- Get a writable blob URL from F&O
- Upload your data package (zip) to the blob
- Call
ImportFromPackagewith the blob URL and project name - Poll
GetExecutionSummaryStatusfor completion - Download error file if needed
Best for: Nightly data loads, migration batches, any scenario with 1,000+ records.
Recurring Integrations
Recurring integrations add a message queue on top of DMF. Instead of manual submissions, data flows through enqueue/dequeue endpoints on a schedule.
- Enqueue — external system pushes data into F&O’s processing queue
- Dequeue — external system pulls exported data from F&O’s outbound queue
🔗 Marcus to Tomoko: “Your daily product feed? Set up a recurring export job. Every night at 2 AM, F&O stages the data. Your middleware calls the dequeue endpoint and picks it up. No manual file drops.”
The Decision Framework
Use this flowchart logic when the exam asks “which integration approach should you use?”
Step 1: How many records?
- Less than ~100 → Consider synchronous (OData / custom service)
- Hundreds to thousands → Asynchronous (DMF)
Step 2: Does the caller need an immediate response?
- Yes → Synchronous (OData for CRUD, custom service for logic)
- No → Asynchronous or event-driven
Step 3: Is it a regular/repeating feed?
- Yes → Recurring integrations
- No, ad-hoc → DM REST API
Step 4: Does F&O need to notify an external system?
- Yes → Business events (Module 25)
Step 5: Does it need bidirectional real-time sync with Dataverse?
- Yes → Dual-write (Module 24)
Decision tree example: E-commerce product sync
Scenario: An e-commerce platform needs its product catalog updated daily from F&O (20,000 products), and needs real-time inventory checks when customers browse.
Product catalog (bulk, scheduled): 20,000 records → asynchronous → repeating schedule → Recurring integration (dequeue)
Inventory check (single, immediate): 1 record, needs instant response → synchronous → OData GET on inventory entity
Two patterns for one integration — that is normal. Most real projects use a mix.
| API | Pattern | Volume | Best For |
|---|---|---|---|
| OData | Synchronous | Low (1–100) | CRUD operations, lookups, Power Platform connectors |
| Custom Services | Synchronous | Low–Medium | Complex business logic, custom contracts |
| DM REST API | Asynchronous | High (1,000+) | Ad-hoc bulk import/export, migrations |
| Recurring Integrations | Asynchronous | High (1,000+) | Scheduled repeating data feeds |
| Business Events | Near-Real-Time | Per-event | Notifications, triggering external workflows |
| Dual-Write | Near-Real-Time | Per-record | Bidirectional Dataverse sync |
Authentication for All APIs
All F&O integration APIs use Azure Active Directory (Microsoft Entra ID) OAuth 2.0 tokens. The typical flow:
- Register an app in Entra ID
- Grant it permissions to the F&O environment
- Use the client credentials flow (
client_id+client_secret) for server-to-server - Include the token as
Authorization: Bearer your-tokenin every request
🔗 Marcus’s security note: “Every integration client gets its own app registration — never share credentials across integrations. If one system is compromised, you revoke that single app without breaking everything else.”
Exam Practice
NexBridge needs to sync 30,000 vendor records from an external ERP into F&O every night. Which integration approach should Marcus recommend?
An e-commerce website needs to check inventory availability in real-time when a customer views a product page. Which API should be used?
Which of the following is a characteristic of the Data Management REST API?
Next up: Data Management Framework — learn how to configure import/export projects, sequence entities, set up field mappings, and manage recurring data jobs using the DMF workspace.