ERP Integration Patterns for Dynamics 365 & Odoo

What ERP integration actually means

ERP integration is the discipline of moving data and triggering actions between your ERP and the other systems that keep the business running — your CRM, e-commerce store, marketing platform, warehouse, payroll, BI tool, and finance consolidation engine. Done well, it makes the ERP behave as a system of record that other software reads from and writes to without anyone retyping a customer address or reconciling an invoice by hand.

Done badly, integration is the single biggest source of hidden cost in an ERP rollout. Netsuite's guidance on ERP integration strategy is blunt about the symptoms: data silos, manual re-entry, inconsistency between systems, compliance risk, and maintenance overhead that grows faster than the business does. The architecture you pick — not the vendor — determines which outcome you get.

The point-to-point scaling trap

Point-to-point integration is the default. Every time a new system arrives, you write a direct connection to every system it needs to talk to. It feels fast on the first link and painful by the fifth.

The reason is arithmetic, not opinion. The number of unique connections in a network of n systems is the triangular number n(n-1)/2 — the same combinatorial basis cited for Metcalfe's law of network value, applied here in reverse. Five systems need 10 connections. Ten systems need 45. Twenty systems need 190. Each connection has to be built, secured, monitored, and changed in lockstep whenever either endpoint alters its API or schema.

The well-documented end state of unmanaged point-to-point growth is what the industry calls 'integration spaghetti' — a brittle, usually undocumented mesh of ad-hoc links with duplicated logic, no central visibility, cascading failures when an API changes, and key-person risk concentrated in whoever remembers how the wires are soldered. The practical guidance for legacy ERP integration with microservices is the same as for greenfield: route traffic through middleware or an API gateway rather than letting direct links multiply.

The five ERP integration patterns that scale

The foundational Enterprise Integration Patterns catalog (Hohpe and Woolf) frames the field with four core styles — File Transfer, Shared Database, Remote Procedure Invocation, and Messaging — that map cleanly onto the patterns SMEs actually choose today. The five below are the working set for an ERP estate.

Point-to-point is fine for a small, stable estate — typically under five systems that rarely change. Hub-and-spoke (middleware or iPaaS) routes every spoke-to-spoke flow through a central hub that handles routing, transformation, adapters, monitoring, and policy, so adding a new system costs one new connection rather than a link to every existing one. Event-driven architecture (EDA) decouples producers from consumers through a broker such as Kafka, RabbitMQ, Solace, or a cloud event broker; producers publish events without knowing who subscribes, which enables temporal decoupling and independent scaling but demands idempotency, schema governance, and distributed tracing. File-based or batch integration moves CSV, XML, or JSON files on a schedule — the oldest pattern, and still the right one for bulk loads and nightly reporting. API-led connectivity layers APIs into System, Process, and Experience tiers so the same backend capability can be composed for many channels without rewrites.

Hub-and-spoke and the iPaaS layer

For most SMEs hitting the limits of point-to-point, the next step is an integration platform as a service. Gartner defines iPaaS as a vendor-managed cloud service that lets end users implement integrations between internal and external applications, services, and data — the successor to on-premise enterprise service buses and EAI middleware, built for SaaS sprawl and hybrid cloud estates.

Microsoft was named a Leader in the 2026 Gartner Magic Quadrant for iPaaS for the eighth consecutive year through Azure Integration Services (Logic Apps, API Management, Service Bus, and Power Automate), which matters directly for SMEs on a Microsoft Dynamics 365 estate. Other established iPaaS players include Boomi, MuleSoft, Workato, Celigo, and Zapier, with selection driven by your existing stack rather than abstract rankings — NetSuite-heavy estates often favour Celigo, Microsoft estates lean on Power Automate and Azure Integration Services, and complex multi-application enterprises tend toward Boomi, MuleSoft, or Workato. Run a proof-of-concept before committing; iPaaS pricing is usage-based, tier-dependent, and rarely published as a list price.

Dynamics 365 integration patterns

Dynamics 365 gives an SME a layered toolkit rather than a single integration surface. Picking the right layer for the job is the whole game.

OData V4 endpoints expose Finance & Operations public data entities at /data for real-time CRUD and queries; Business Central uses REST/OData V4 as its primary web-service surface. This is the right choice for small-to-medium-volume lookups and transactional writes, but not for bulk loads of more than a few hundred thousand records, where batch tools win. Power Automate provides low-code orchestration with dedicated 'Dynamics 365 Fin & Ops' and 'Business Central' connectors, ideal for approvals, notifications, and cross-system automation triggered by Business Events.

Dataverse virtual entities let F&O or Business Central act as a virtual data source inside Dataverse, giving full CRUD from model-driven Power Apps without copying the data — business logic runs server-side, and Microsoft documents virtual entity overhead of less than 30 milliseconds per call when F&O and Dataverse are co-located in the same Azure region. Business Events plus Azure Event Grid or Service Bus push near-real-time, idempotent (control-numbered) notifications of processes such as purchase-order confirmation; this is mature in F&O and in preview for Business Central. Business Central also offers native webhooks via the v2.0 subscriptions API, with mandatory handshake validation — the preferred push mechanism, replacing the delta-link approach that was deprecated in version 23 and removed in version 24.

For tightly coupled bidirectional flows between F&O and the Power Platform, Dual-write provides near-real-time sync with out-of-box maps for customers, products, and vendors. For bulk and migration, the Data Management Framework (DMF) recurring integrations and package REST API is the F&O workhorse, supporting enqueue/dequeue/ack for reliable file and data-package exchange, with XSLT-based transforms applied on inbound data.

• →Real-time small payloads: OData V4 or Dataverse virtual entities
• →Notifications and change events: Business Events (F&O) or webhooks (Business Central)
• →Shared master data with immediate CRM parity: Dual-write between F&O and Dataverse
• →Bulk import, export, and migration: Data Management Framework recurring integrations and package REST API
• →Low-code glue, approvals, and notifications: Power Automate with the D365 connectors

Odoo integration patterns

Odoo spans the spectrum from low-level ORM access to a full OCA connector framework, and the right pattern depends on volume, reliability requirements, and how much custom code you are willing to maintain.

The Odoo 19 External API introduced the JSON-2 endpoint (/json/2/<model>/<method>) with Bearer-token API-key authentication, standard HTTP status codes (200 on success, 4xx/5xx on error), and named parameters. It is the modern replacement for the verbose XML-RPC and JSON-RPC endpoints, which are scheduled for removal in Odoo 22 (fall 2028) and Online 21.1 (winter 2027). It exposes search, read, search_read, create, write, and unlink operations on every model, making it the backbone of reliable server-to-server sync for e-commerce, BI, and automation. Always authenticate with API keys (Odoo 14+) under a dedicated bot user with minimal rights rather than a named human's password.

For high-volume or flaky bidirectional sync, the OCA connector framework provides an opinionated async job-queue architecture (the queue_job module) with components, bindings, event handlers, and checkpoints — battle-tested for e-commerce and marketplaces. The learning curve is real (job runners, channels, event handling), but it is the correct choice when reliability and retry matter. Odoo has no native full REST surface, so developers expose custom endpoints via @http.route controllers, or use the OCA rest-framework (base_rest with OpenAPI, plus a FastAPI integration addon with Pydantic and JWT/API-key auth) for clean, self-documenting APIs.

Webhooks are buildable in Odoo 17+ through Studio or Automated Actions triggered by an external POST, and outbound notifications can be fired on create/write/delete the same way. They are lightweight event glue — often paired with Zapier or Make — but auth, idempotency, and retries must be hand-rolled. File-based CSV/XLSX import and export remains the zero-code fallback, ideal for one-off loads, initial migration, and bulk price, inventory, or accounting updates where real-time sync is not required.

• →One-off loads and non-technical users: built-in CSV/XLSX import wizard with external IDs
• →Lightweight inbound/outbound events: Studio Automated Actions as webhooks, paired with Zapier or Make
• →Ongoing reliable CRUD and sync: JSON-2 External API with API-key auth
• →Complex high-volume bidirectional sync: OCA connector framework with queue_job
• →Partner-facing or microservice APIs: OCA rest-framework (base_rest, FastAPI addon)

A hybrid middle path and the SME decision framework

Few SMEs run a single pattern end to end. The widely recommended middle path is hybrid ERP integration: a few stable point-to-point or scheduled batch links for systems that rarely change, plus iPaaS or middleware for the complex, frequently-changing flows. This is pragmatic for manufacturers and SMEs that need to ship now without over-engineering a pure API-led estate.

The contextual decision framework an SME should run before committing looks at five factors. Number of systems: point-to-point is acceptable under roughly five stable endpoints, beyond which a hub pays for itself. Latency tolerance: real-time order sync has a very different cost profile than nightly reporting. In-house skills: low-code iPaaS or Power Automate shifts work away from scarce integration developers. Total cost of ownership: maintenance dwarfs initial build, so optimise for the second and third year, not go-live. Ecosystem fit: pre-built connectors for your ERP plus your commerce, CRM, and finance stack save months of custom work.

Rolling out integration alongside your implementation

Integration decisions belong early in the implementation lifecycle, not as a post-go-live surprise. If you are scoping an implementation, treat integration patterns as a workstream of their own — they influence data migration cut-over, the master-data management plan, and the change-management effort for every team whose workflow now depends on a flow running correctly in the background.

A pragmatic phased rollout for an SME is: stabilise the ERP as system of record first; add file-based or batch integration for the highest-volume, lowest-latency-sensitivity flows (e-commerce orders, price lists); then layer real-time or event-driven flows for the few processes that genuinely need sub-minute parity; and finally consolidate onto iPaaS once the team understands the flows well enough to standardise. This sequence keeps risk down and avoids buying an iPaaS licence before you know what you need it to do.