The Complete Guide to Enterprise System Integrations

In twenty-two years of building and running enterprise systems, I have learned that the interesting problems almost never live inside a single application. They live in the gaps between applications. The ERP holds the money and the master data. The CRM holds the customer relationship. The HRMS holds the people. The warehouse system holds the stock. The CMMS holds the assets. Each one is competent in its own lane, and each one is blind to everything happening in the others until you connect them. This page is my attempt to map those connections in one place, and to point you at the individual guide for whichever pairing you actually need to build.

How to use this page: this is a hub, not a how-to. It gives you the shared mental model that every integration follows, then a directory of deep guides organised by domain. Start with the concept pillar, enterprise system integration explained, if the fundamentals are new to you, then jump to the specific pairing you need to deliver.

1. Why system-to-system integration is the backbone of digital operations

A digital operation is not a collection of applications. It is a flow of information that crosses those applications without a human retyping it at every boundary. When a customer places an order, that single event should ripple outward automatically: the CRM records the opportunity as won, the ERP raises the sales order and reserves inventory, the warehouse system picks and ships, the finance ledger recognises the revenue, and the customer portal shows the tracking number. If any one of those steps depends on somebody exporting a spreadsheet and emailing it to the next team, the operation is not digital. It is manual work wearing a digital costume.

That is why integration is the backbone rather than a nice-to-have. The systems themselves are largely commodities now; you can buy a competent ERP, a competent CRM and a competent warehouse system off the shelf. What separates a smooth operation from a chaotic one is whether those systems share a single, trustworthy version of the truth. Master data such as customers, products, vendors, accounts and cost centres has to mean the same thing everywhere, and transactions have to move between systems reliably, in the right order, with the right error handling when something goes wrong.

The costs of getting this wrong are quiet but relentless. Duplicate data entry burns hours every day. Reconciliation between systems that disagree becomes a monthly ritual. Reports contradict each other because each system counts slightly differently. Customers get told one thing by sales and another by fulfilment. None of these show up as a single dramatic failure, which is exactly why they are so often tolerated for years. Integration done well removes them at the source. That is the return, and it is why I treat integration architecture as a first-class discipline rather than an afterthought bolted on once the applications are chosen.

2. The integration hub model

The single most useful way to picture an enterprise landscape is as a hub with spokes. The ERP sits at the centre because it owns the financial truth and most of the shared master data. Everything else connects to it, either directly or through an integration layer, and the ERP becomes the system of record that keeps the whole estate consistent. The diagram below is the shape I sketch on a whiteboard at the start of almost every integration engagement.

The hub model is a simplification, and in a large estate you rarely wire every spoke directly into the ERP. Instead an integration layer, whether that is a middleware platform, an integration-platform-as-a-service, or a set of well-governed APIs, sits between the hub and the spokes so the ERP is not burdened with dozens of point-to-point connections. But the mental model holds: there is a centre that owns the truth, and there are edges that produce and consume that truth. Once you see the landscape this way, every integration question becomes concrete. What data flows along this spoke? In which direction? How often? Who is the master for each field? What happens when the message fails? Those questions are the whole job, and they are the same questions on every spoke, which is why a shared structure across the guides is so useful.

3. How to read these integration guides

Every deep guide in this directory follows the same structure, deliberately, so that once you have read one you can navigate any of them quickly. Integration problems rhyme across domains, and the questions you must answer for a CRM-to-ERP link are structurally identical to the questions for a WMS-to-ERP link even though the data is different. Each guide walks through the same seven lenses:

• Architecture: what sits between the two systems. Direct API calls, a middleware or integration-platform layer, a message broker, a file exchange, or a database-level link. This decides how coupled the systems are and how gracefully the integration degrades when one side is unavailable.
• Data flow: which fields move, in which direction, and which system is the master for each. This is where you settle the ownership arguments up front, for example that the ERP owns the customer credit limit while the CRM owns the contact preferences, so neither side overwrites the other's authority.
• Process flow: the business event that triggers the exchange and the sequence of steps it sets off. An order placed, an employee hired, a goods receipt posted. The integration exists to serve a process, and the process defines what good looks like.
• Real-time versus batch: whether the exchange happens the instant the event occurs or on a schedule. Real-time suits customer-facing and time-sensitive flows; batch suits high-volume reconciliation and reporting flows. Choosing wrongly here is one of the most common and most expensive mistakes, so each guide is explicit about it.
• Security: how the two systems authenticate to each other, how the data is protected in transit, and how access is scoped. Authentication standards such as OAuth 2.0, transport encryption, and least-privilege service accounts belong in the design from day one, not bolted on after a review flags them.
• KPIs: how you know the integration is healthy. Message success rate, latency, error backlog, reconciliation variance, and the business metric the integration was meant to improve. An integration with no monitoring is a silent single point of failure.
• Data objects exchanged: the concrete records that move, such as customer, product, sales order, invoice, employee, purchase order, goods receipt, work order or payment. Naming them precisely prevents the vague scope that sinks integration projects.

Read against those seven lenses, any integration becomes legible. When you open a specific guide below, you will find these same headings, which means you can skim straight to the lens you are stuck on rather than reading the whole thing end to end.

4. ERP core integrations

These are the spokes that connect directly to the financial and master-data core. If you get these right, the rest of the estate has a stable centre to orbit. Each link below goes deep on the architecture, data flow, timing and security for that specific pairing.

• CRM and ERP · keep the customer record, quotes and orders consistent between the relationship system and the financial system of record.
• HRMS and ERP · sync the employee master, org structure and cost-centre assignments so finance and operations share one view of the workforce.
• Payroll and ERP · post payroll runs into the general ledger accurately and post the funding requirement without manual journals.
• eCommerce and ERP · flow online orders, stock levels and pricing between the storefront and the back office in near real time.
• POS and ERP · consolidate point-of-sale transactions, inventory movements and cash reconciliation from the shop floor into finance.
• Procurement and ERP · connect requisitions, purchase orders and approvals to the financial commitment and three-way match.
• Vendor Portal and ERP · let suppliers submit invoices, confirm orders and check payment status against live ERP data.
• Customer Portal and ERP · expose orders, invoices, statements and delivery status to customers from the authoritative source.
• WMS and ERP · reconcile inventory, picks, receipts and shipments between the warehouse floor and the financial stock ledger.
• Payment Gateway and ERP · capture payments, settlements and refunds and match them automatically to open receivables.
• Banking and ERP · automate statement import, payment file export and reconciliation using standards such as ISO 20022.
• CMMS and ERP · link maintenance work orders, parts consumption and asset costs to procurement and the financial ledger.
• CAFM and ERP · connect facility space, service charges and maintenance cost back to finance and the property portfolio.

5. Microsoft and Business Central integrations

Microsoft Dynamics 365 Business Central sits at the centre of a large number of mid-market estates, and its integrations with the wider Microsoft ecosystem and with commerce platforms are among the most common projects I am asked to scope. These guides cover the pairings I see most often.

• Business Central and Shopify · sync products, inventory, orders and fulfilment between the Shopify storefront and the Business Central back office.
• Business Central and Power BI · surface live financial and operational data in governed dashboards without exporting spreadsheets.
• Business Central and Teams · bring approvals, record lookups and notifications into the collaboration surface where people already work.
• Business Central and Outlook · create quotes, invoices and customer lookups directly from the inbox against live ERP data.
• Dynamics CRM and Business Central · connect the sales pipeline to order fulfilment and finance across the two Dynamics applications.
• Oracle Fusion and Shopify · integrate a Shopify storefront with Oracle Fusion for order, inventory and financial synchronisation.

6. Asset, CMMS and OT integrations

This is the domain I have spent most of my career in, and it is where enterprise IT meets operational technology. Connecting the maintenance and asset systems to the sensors, control systems and spatial data that describe the physical world is a distinct discipline with its own timing, protocol and reliability concerns. The guides below cover the pairings that turn a CMMS or EAM from a work-order logbook into a live operational hub.

• CMMS and ERP · the financial spine for maintenance: work-order cost, parts and asset value flowing to the ledger.
• Digital Twin and CMMS · bind the virtual asset model to real maintenance history so the twin reflects the asset's true condition.
• IoT and CMMS · turn sensor readings into condition-based and predictive work orders inside the maintenance system.
• Computer Vision and CMMS · convert image-based inspection findings into structured defects and work orders automatically.
• GIS and CMMS · link spatial asset location and network topology to maintenance records for distributed infrastructure.
• SCADA and CMMS · raise maintenance work from control-system alarms and runtime data without manual re-keying.
• SCADA and EAM · feed operational-technology signals into enterprise asset management for reliability and lifecycle decisions.
• SCADA and Historian · stream and store high-resolution process data reliably for trending and analysis.
• SCADA and Digital Twin · drive a live digital twin from real control-system telemetry for simulation and monitoring.
• BMS and CAFM · a reference architecture for connecting building management systems to facility management workflows.

7. IoT and analytics integrations

The final cluster is the sensing and intelligence layer. These integrations connect the Internet of Things to analytics, building systems, energy management and fleet operations, using protocols such as MQTT and OPC UA to move telemetry at scale. This is where raw signal becomes operational insight.

• IoT and AI · feed device telemetry into machine-learning models for anomaly detection and prediction at the edge and in the cloud.
• SCADA and AI · apply analytics and machine learning to control-system data for optimisation and early fault detection.
• IoT and BMS · extend building management with distributed sensors for finer-grained comfort and efficiency control.
• IoT and EMS · connect metering and sensing to energy management systems for consumption visibility and reduction.
• IoT and Fleet Management · integrate telematics and vehicle sensors into fleet operations for tracking, utilisation and maintenance.

A word of caution before you start any of these: an integration is a permanent commitment, not a project that ends. Every link you build becomes something that has to be monitored, versioned and maintained as both connected systems evolve. The most common failure I see is teams building a large number of point-to-point connections in a burst of enthusiasm, then discovering two years later that nobody can safely upgrade either system because the web of undocumented integrations will break. Build fewer, better-governed connections through a proper integration layer, document the data ownership on each spoke, and monitor every link. Integration debt is as real as code debt and far harder to see until it stops you moving.

8. Choosing your integration approach

Once you know which spoke you are building, the next decision is how to build it, and this is where the concept pillars do the heavy lifting. The two questions that decide the shape of any integration are the pattern and the timing. On pattern, you are choosing between direct point-to-point calls, a middleware or integration-platform layer that mediates between systems, a message broker that decouples producers from consumers, or a batch file exchange. Each has a place, and the right choice depends on volume, coupling tolerance and how many systems ultimately need the same data. For the full decision framework, read how to choose the right integration method, which walks through the trade-offs in detail.

On timing, you are choosing between real-time and batch. Real-time integration, typically over REST APIs or a message broker, suits anything a person or customer is waiting on: an order confirmation, a stock check, a payment authorisation. Batch integration, often a scheduled file or bulk API load, suits high-volume flows where a few minutes or hours of delay is harmless: overnight financial reconciliation, master-data refreshes, reporting extracts. Trying to make everything real-time is expensive and fragile; leaving everything to batch makes the operation feel sluggish and disconnected. The skill is deciding, spoke by spoke, which flows genuinely need immediacy and which are better served by a robust nightly run.

My advice, drawn from more of these projects than I can count, is to resist cleverness. The best integration is the simplest one that meets the real business requirement, built on standard protocols, with clear data ownership, proper security from the first line, and monitoring that tells you the moment a link goes quiet. Before you build anything, read the concept pillar, enterprise system integration explained, to fix the vocabulary and the principles, then use the specific guide for your pairing to get the concrete data objects and process flow right. Ambition belongs in what the integrated operation can do, not in the plumbing that connects it.

9. References

The guides in this directory lean on a small set of widely adopted, vendor-neutral standards rather than any single product's proprietary approach. Understanding these by name will help you read any integration design, because they recur across almost every spoke:

• REST · the dominant architectural style for web APIs, using standard HTTP verbs and resources. Most modern application-to-application integrations expose and consume REST endpoints.
• SOAP · the older XML-based web-services protocol, still common in established enterprise and financial systems where strict contracts and envelope-level security are required.
• OAuth 2.0 · the standard authorisation framework for granting one system scoped, token-based access to another without sharing credentials, and the default for securing REST integrations.
• ISO 20022 · the international standard for financial-messaging data, increasingly the common language for bank-to-ERP payment and statement exchange.
• MQTT · a lightweight publish-and-subscribe messaging protocol designed for constrained devices and unreliable networks, widely used to move IoT telemetry.
• OPC UA · the platform-independent standard for industrial data exchange, the common bridge between operational-technology systems such as SCADA and the enterprise and analytics layers.

None of these is exotic, and none is tied to a particular vendor. When a design proposes a proprietary connector where one of these open standards would do the job, that is worth questioning, because standards outlive products and keep your estate portable.

Final thoughts

The reason I built this hub is that integration questions almost always arrive one pairing at a time. Someone needs the warehouse system talking to the ERP, or the storefront talking to Business Central, or the sensors talking to the CMMS, and they go looking for the answer to that one problem. That is the right instinct, and each guide in the directory above answers one of those problems in depth. But the pairings are not really separate. They are all spokes on the same wheel, and the discipline that makes any one of them succeed, clear data ownership, the right pattern, honest timing choices, security from the start and monitoring that never lets a link fail silently, is the same discipline that makes all of them succeed.

Start with whichever spoke is causing you pain today. Read the concept pillar to get the vocabulary, use the method guide to choose your approach, then follow the specific pairing guide to build it well. Do that consistently across the estate and, over time, you stop having an integration problem at all. You have a connected operation, where a single business event ripples through every system that needs to know about it, automatically and reliably, which is the entire point of building any of this in the first place.

Related reading: Enterprise system integration explained, How to choose the right integration method, CRM and ERP integration, WMS and ERP integration, CMMS and ERP integration.