Real-Time Integration Use Cases

The word "real-time" gets thrown around in integration projects the way "AI" gets thrown around everywhere else: as a badge of seriousness rather than a considered engineering decision. Somewhere in most requirements documents there is a line that says the systems must be integrated "in real time," written by someone who has never been asked to defend what that costs. In more than two decades of connecting ERP, EAM, CAFM and line-of-business systems, I have learned that the honest question is never "should this be real-time?" It is "does a delay here change the outcome?" When the answer is yes, real-time integration earns every dirham it costs. When the answer is no, it is an expensive habit. This guide walks through the use cases where it genuinely pays, and is equally candid about where it does not.

Before we get into specific use cases, it helps to place real-time integration in the wider picture. If you want the full grounding in how systems talk to each other at all, the patterns, the middleware, the trade-offs, start with the pillar guide, enterprise system integration explained. Everything below assumes you already understand that integration is a spectrum, and that real-time sits at the expensive, high-value end of it.

The test I apply to every "real-time" requirement: if the data arrived five minutes late, would a decision be made differently, would money be lost, or would a customer notice? If none of those are true, you do not have a real-time requirement, you have a real-time preference, and preferences do not justify the operational cost of streaming architecture. For the deeper comparison of the two models, see batch vs real-time integration.

1. What real-time integration enables

Real-time integration means that when data changes in one system, the change propagates to the systems that depend on it within seconds, not on the next scheduled batch run. The mechanism is usually event-driven: a business event happens, an event is published, and interested systems react to it more or less immediately. This is a different mental model from the traditional overnight extract-transform-load job that moves yesterday's data into the warehouse while everyone sleeps.

What that capability actually buys you falls into a handful of categories. It buys immediacy of information, where a number a user sees reflects the state of the world seconds ago rather than hours ago. It buys automated reaction, where one system's event triggers another system's action with no human in the loop and no waiting. It buys consistency across channels, where a customer looking at the website, the mobile app and the call-centre screen sees the same figure because they are all reading state that was updated the moment it changed. And in the operational world it buys time to respond, where a sensor reading or an alarm reaches the person who can act on it while the window to act is still open.

None of those benefits are free, and that is the point of this whole article. Event-driven, real-time architecture is more complex to build, harder to test, and more demanding to operate than a nightly batch. It introduces ordering problems, duplicate-delivery problems, and failure modes that batch jobs simply do not have. So the discipline is to reach for it only where one of those four benefits genuinely changes the business outcome. The rest of this guide is a tour of where it does. For the underlying transport mechanism that makes much of this possible, the companion piece on what is event streaming is worth reading alongside this one.

2. Order-to-cash in real time

The order-to-cash flow is where real-time integration most obviously earns its keep in a commercial business, because every step in it is time-sensitive and customer-facing. When a customer places an order online, a whole sequence needs to happen quickly: the order has to be recorded, the payment authorised, the inventory reserved, and the fulfilment process kicked off. If any of those steps waits for an overnight batch, the customer experience degrades and, worse, you risk selling stock you no longer have.

Consider the concrete failure a batch approach creates here. Two customers buy the last unit of an item within the same hour. In a batch world where inventory only reconciles overnight, both orders are accepted, both customers get a confirmation, and one of them gets an apologetic email the next day. That is a real cost: a refund, a lost sale, a damaged relationship, and sometimes a chargeback. Real-time inventory reservation at the moment of purchase prevents it, because the second customer is told the item is gone before they commit.

The same immediacy matters on the fulfilment side. When the order is confirmed and paid, an event should flow straight to the warehouse or third-party logistics system so picking can begin. In a modern operation running a system like Microsoft Dynamics 365 Business Central for finance and inventory, this is exactly the kind of flow you wire through its APIs so the storefront, the ERP and the fulfilment partner stay in step. If you are working in that stack specifically, the mechanics are covered in Business Central APIs and integrations. The order-to-cash flow is the textbook case where real-time is not a luxury: the outcome, whether you sell what you have and get it moving, changes directly with the latency.

3. Inventory and availability

Inventory deserves its own section because "available to promise" is one of the highest-value real-time signals in any business that sells or allocates physical things. The number a customer or a salesperson sees when they ask "can I have this, and when?" is only trustworthy if it reflects reservations, receipts and shipments as they happen. Stale availability is not a cosmetic problem. It leads directly to overselling, to disappointed customers, and to the manual firefighting that eats a fulfilment team's day.

This is especially acute for businesses selling the same stock across multiple channels: a website, a marketplace, a physical store, a wholesale desk. Each channel is drawing down from a shared pool, and if the channels only synchronise on a schedule, they will oversell each other in the gaps. Real-time inventory integration, where every sale and every receipt immediately updates a shared availability view that all channels read from, is the mechanism that keeps a multi-channel operation honest. The value is proportional to how fast your stock moves and how thin your margins are on the mistakes.

There is nuance here worth stating plainly. Not every inventory number needs to be real-time. The available-to-promise figure a customer sees at the point of sale is time-critical. The aggregate stock-on-hand report the finance team reviews weekly is not; a nightly refresh serves it perfectly well and costs a fraction as much to maintain. The skill is separating the fast-moving, decision-driving signal from the slow-moving, reporting-oriented one, and only paying the real-time premium for the former.

4. Payments and fraud detection

Payments are the clearest example of a domain where latency is not just a quality-of-service issue but a hard functional requirement. When a card is presented, the authorisation decision, approve or decline, has to be made in the moment, because the transaction physically cannot complete without it. There is no batch version of a card authorisation. The customer is standing at the terminal or watching a spinner on a checkout page, and the answer has to come back in a second or two.

Fraud detection rides on the same real-time rails and is the higher-value half of the story. Modern fraud screening evaluates a transaction against behavioural signals, device and location data, velocity checks, and risk models at the instant of authorisation, because the only useful moment to stop a fraudulent transaction is before it is approved. A fraud model that scored transactions overnight would be an audit tool, not a defence; the money would already be gone. This is real-time integration where the delay does not merely change the outcome, it eliminates the ability to act at all.

The honest qualification is that the real-time requirement here belongs to the authorisation and fraud-scoring path specifically. The downstream flows that payments feed, settlement reconciliation, accounting entries, revenue reporting, are perfectly well served by batch processing at end of day. It is common to see a system correctly built with a real-time authorisation path and a batch settlement path, and that split is not a compromise, it is the right design. Money moving through the gate needs real-time; money being counted after the fact does not.

5. IoT and predictive maintenance

Move from the commercial world to the operational one and real-time integration takes on a different but equally concrete value: time to respond to physical conditions. When a sensor on a pump, a chiller, a generator or a cold-storage unit reports a reading that crosses a threshold, the value of that reading decays fast. A temperature excursion in a pharmaceutical cold store detected in real time is a work order and a saved batch. The same excursion detected in tomorrow's batch report is a written-off inventory and an insurance claim.

The pattern that makes this pay is the integration between the sensing layer and the maintenance system of record. A reading crosses a limit, an event is raised, and a work order is created in the CMMS or EAM automatically, routed to the right team with the asset context attached, while there is still time to intervene. That closed loop, from physical signal to dispatched technician without a human noticing a chart first, is where operational real-time integration delivers. The mechanics of wiring sensor data into the maintenance backbone are covered in IoT integration with CMMS.

The honest limitation: real-time sensor integration only creates value where the failure mode gives you a usable window to act and where someone is actually positioned to act on the alert. Streaming vibration data every few seconds from an asset whose failures are sudden, or into a queue nobody watches out of hours, generates cost and noise without changing a single outcome. The real-time value is in the response, not the reading, and if the response cannot happen faster because of the data, the data does not need to be real-time.

6. A single customer view

Customer experience is the domain where real-time integration is most often demanded and most often over-specified, so it deserves a careful look. The legitimate case is real: when a customer contacts you, the person or system serving them should see the current state, the order placed an hour ago, the payment that just cleared, the support ticket raised this morning. A call-centre agent looking at yesterday's snapshot while the customer describes something that happened this morning is a familiar and avoidable source of friction.

Where a genuinely unified, up-to-the-second customer view matters is in interactions that span channels within a short window. A customer who abandons a web checkout, then calls support two minutes later, expects the agent to know what they were doing. That continuity requires the systems behind the two channels to share state in near real time. For businesses whose competitive edge is service quality, that immediacy is worth paying for.

But this is also the area where I most often talk clients down from a real-time requirement they do not have. A great deal of what gets sold as "360-degree real-time customer view" is really reporting and segmentation: lifetime value, purchase history, marketing propensity. None of that changes minute to minute, and a nightly consolidation into a customer data platform serves it perfectly. Reserve the real-time integration for the operational, in-the-moment interactions where a stale view actually breaks the conversation, and let the analytical view refresh on a batch schedule. Building everything real-time because "customer experience is critical" is how integration budgets get spent on latency nobody experiences.

7. Alerts and operational response

The unifying thread across the operational use cases is this: real-time integration is most defensible when its output is an alert that triggers a human or automated response with a closing window. This is broader than IoT. It covers a fraud alert to a monitoring team, a stock-out alert to a buyer, an SLA-breach warning to a service manager, a threshold alert to a plant operator. In each case the value is the same shape: something changed, someone or something needs to act, and the sooner the alert lands the more the response is worth.

What makes an alert-driven real-time integration succeed or fail is rarely the speed of the pipe. It is whether the alert reaches a place where action can actually be taken, and whether the recipient can distinguish a signal that demands action from the background hum. I have seen beautifully engineered real-time alert flows deliver into inboxes and channels that everyone had long since muted, which converts a real-time capability into an expensive way to be ignored quickly instead of slowly. The integration is only as valuable as the response process on the other end of it.

So the design question for any alert use case is two-sided. Is the underlying event genuinely time-critical, meaning a faster alert produces a materially better response? And is there a real, staffed, capable response process ready to receive it? Only when both answers are yes does the real-time investment return. Where the event is time-critical but the response is not staffed, fix the response process first; the fastest alert in the world changes nothing if no one is there to act on it.

8. When real-time is not worth it (honest)

This is the section the vendor decks skip, and it is the most important one. A great many integration requirements are better served by batch, and building them real-time is a net loss: more cost, more fragility, and no outcome improvement. Being able to name those cases is as much a mark of an integration specialist as being able to build the real-time flows.

The clearest category is reporting and analytics. Management dashboards, financial reports, trend analysis, and business intelligence overwhelmingly work fine on data that is a few hours old. A revenue report that reflects yesterday's close is exactly what the finance team wants; making it update every second adds cost and, if anything, invites people to react to noise. The second category is bulk and periodic processes: payroll, month-end close, statement generation, mass data reconciliation. These are inherently scheduled activities, and forcing them into an event-driven model fights their nature. The third is reference and master data that changes slowly: a product catalogue, a chart of accounts, a supplier list. A nightly sync is more than adequate, and streaming every rare change is effort spent on a problem that does not exist.

There is also a hard-nosed cost argument that applies even where real-time is technically feasible. Event-driven architecture carries a permanent operational tax: more moving parts to monitor, harder failure recovery, ordering and duplicate-handling logic, and the specialist skills to run it. If the business value of immediacy is marginal, that tax is not worth paying. I have advised clients to deliberately de-scope a "real-time" requirement to a fifteen-minute micro-batch, which captured the near-total of the value at a fraction of the operational burden. Choosing the right latency is an engineering decision with a cost on both sides, and the correct answer is frequently "fast enough," not "instant." The full framework for that decision lives in batch vs real-time integration.

9. The use cases summarized

It helps to see the pattern in one view. On the operational and commercial side, the recurring shape is that a trigger event produces value only if a reaction follows it quickly. The two flows below are the canonical examples: an online order that must instantly reserve stock and start fulfilment, and a sensor reading that must instantly raise an alert and open a work order. Both share the same anatomy, an event that demands an immediate downstream action, which is precisely the anatomy that justifies real-time integration.

The table below widens the lens to the full set of use cases covered in this guide, pairing each trigger event with the real-time value it produces and the kind of technology usually behind it. Read it as a triage aid: where the real-time value column describes something the business would genuinely feel, real-time integration is justified. Where it does not, batch is the honest answer.

The shape of the table is deliberate. The first five rows are where real-time earns its place, and they all share the trigger-then-immediate-reaction anatomy from the diagram. The last two rows are included precisely because they look like integration requirements but are not real-time ones, and recognising them is what keeps a program's cost proportionate to its value.

10. References

The claims in this guide rest on well-established integration and operations practice rather than any single proprietary source. For readers who want to go deeper into the primary concepts, the following are sound, vendor-neutral starting points.

• Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns (Addison-Wesley). The reference catalogue of messaging and event-driven integration patterns that underpins most of the flows described here.
• Martin Fowler, "Event-Driven Architecture" and "What do you mean by Event-Driven?" essays at martinfowler.com. Clear, practitioner-level explanations of when event-driven and real-time approaches apply.
• Apache Kafka documentation (kafka.apache.org). The de facto reference for the event-streaming transport that carries many real-time integrations.
• Microsoft Dynamics 365 Business Central developer and API documentation (learn.microsoft.com). Primary source for the ERP integration mechanics referenced in the order-to-cash section.
• PCI Security Standards Council resources (pcisecuritystandards.org) for the real-time authorisation and fraud-screening context in the payments section.

Final thoughts

Real-time integration is not a maturity level you upgrade the whole estate to, and it is not a badge that makes an architecture more serious. It is a targeted tool for a specific shape of problem: an event happens, a reaction must follow quickly, and the speed of that reaction changes the outcome in money, in risk, or in customer experience. Order-to-cash, live inventory, payment authorisation, fraud screening, sensor-driven maintenance, and in-the-moment customer service all have that shape, and on those flows real-time integration returns its cost many times over.

The equal and opposite discipline is refusing to apply it where the shape is absent. Reporting, analytics, periodic bulk processing, and slow-moving master data do not become better for being streamed; they become more expensive and more fragile. The practitioner's contribution is not the ability to build real-time flows, which any competent team can learn, but the judgement to know which requirements genuinely need them and which are preferences dressed up in urgent language. Point real-time integration at the events where a delay changes the outcome, and let everything else run on a schedule. That is how you get the immediacy where it matters without paying for latency nobody feels.

Related reading: Enterprise system integration explained, Batch vs real-time integration, What is event streaming, IoT integration with CMMS, Business Central APIs and integrations.