White Paper: Real-Time or Right-Time? Choosing How Systems Exchange Data

A white paper for business and technology leaders

Executive summary

A customer places an order at 4:45 p.m. The sales team can see it. The warehouse cannot. At 5:00 p.m., the day’s shipping list closes, and the order waits until tomorrow.

The integration worked in a technical sense: the order eventually arrived. It simply arrived too late to do what the business needed.

Now consider a different exchange. Finance receives a sales report every morning at 7:00 a.m. The report is complete, accurate, and ready before anyone starts reviewing it. Updating it every few seconds would make little difference to the decisions it supports.

Both examples are about timing, but they call for different solutions. Yet integration projects are often given a single instruction: “Make it real-time.”

This paper asks a more useful question: When does the information need to arrive for someone to do their job well? The answer helps organizations choose between immediate requests, event-based updates, scheduled transfers, and access to data held elsewhere. It also brings less visible issues into the discussion: who owns the data, what happens when an exchange fails, and whether two systems mean the same thing when they use the same word.

Introduction: Why timing deserves its own decision

Most organizations have built their technology landscape over many years. Sales may work in a CRM platform, finance in an ERP system, customer service in another application, and operations in a mix of specialized tools. Trouble begins when someone must act using information that has not reached them.

The usual response is to connect the applications more closely. That may be necessary, but “connected” does not tell us enough. A connection can deliver a record in one second, ten minutes, or the next morning. It can also deliver an incorrect record very quickly.

Research gives some sense of why the underlying data work matters. McKinsey estimates that as much as 70% of the effort involved in developing AI-based solutions can be spent wrangling and harmonizing data. That estimate concerns AI development, not integration projects generally. It does illustrate the work created when information is difficult to combine and trust.

Integration influences application choices, too. BCG found that 53% of surveyed decision-makers who favored application suites cited seamless integration as their top technical benefit. Among respondents who preferred specialized applications, 66% named complex integration as a top risk. Neither result says that one type of application landscape is right for every company. Both show how seriously leaders take the work of making applications operate together.

Meanwhile, Deloitte reports that 55% of respondents in its 2025 Tech Value survey invest in data modernization. As those investments proceed, organizations need to decide how information will reach the people, reports, and processes that rely on it.

The choice is not simply “fast or slow.” It is about knowing what happens if the information is late.

Follow the decision, then set the clock

Imagine a customer service agent checking whether a replacement part can ship today. If the available quantity changes throughout the afternoon, the agent may need a current answer before making a promise. Yesterday’s inventory figure could cause a failed delivery and an awkward second call.

The same organization might send a weekly inventory trend to its planning team. That report does not need every change the moment it happens. It needs a consistent cutoff and numbers that reconcile.

These are two uses of inventory data with different clocks. A useful requirements discussion begins by writing down the action, the person taking it, and the latest acceptable arrival time for the information. “As soon as possible” is difficult to build against. “Before the agent confirms shipment” is testable.

Five questions help make the requirement clear:

1. Who needs the information, and what will they do with it?
2. How old can it be before the decision becomes unreliable?
3. What happens if the source system is unavailable?
4. How will the user know the information is delayed?
5. Which system is responsible for the official answer?

The last question can be uncomfortable. Sales and finance might both hold a customer address, but only one may be authorized to change the billing address. Faster synchronization will not settle that disagreement. The teams need an ownership rule before they need another interface.

The four common ways to exchange information

An immediate request is familiar. One application asks another a question and waits for an answer. At checkout, a system might request payment authorization before confirming an order. A service agent might ask an inventory system for current availability. This approach suits decisions that cannot continue without a response. Its weakness is equally plain: if the responding system is slow or unavailable, the person waiting may be stuck.

An event works differently. One system records that something happened, such as “order placed” or “shipment dispatched.” Other systems receive that notice and do their own work. The original action does not have to wait for every downstream task to finish. This can work well when several teams need to react to the same change. It also requires care: a recipient may receive an event later than expected, receive it twice, or fail to process it.

A scheduled transfer groups records and moves them at agreed intervals. This is often sensible for reconciliations, historical reporting, or large volumes of changes that do not need individual attention as they occur. The schedule should be visible to the people using the data. “Updated daily” means little if nobody knows whether that happened at 6:00 a.m. or 11:00 p.m.

Finally, an application can show information held in another system without storing its own copy. This may be useful when a service agent needs to view an invoice kept in the finance system. It avoids maintaining two versions, though the experience depends on the source being available when the agent asks.

Salesforce’s integration guidance separates immediate requests, where the caller waits, from exchanges where work continues and the result follows later. It also documents batch transfers and access to externally held data as distinct patterns. These distinctions apply well beyond Salesforce.

Business need	A pattern to consider	Question to settle first
Confirm payment before showing success	Immediate request and response	What will the customer see if no response arrives?
Notify several systems that an order shipped	Event-based update	Who checks that each system processed the event?
Prepare a complete sales report each morning	Scheduled transfer	What is the agreed reporting cutoff?
Let an agent view an old invoice	Access to data in the finance system	What happens if that system is temporarily unavailable?

These are starting points, not fixed rules. The right answer depends on the process and the consequences of delay.

A sale is not an order

Consider a company that tracks opportunities in Salesforce and creates orders in an ERP system. A seller marks a deal as won. That is an important moment for the sales team, but it does not necessarily mean the ERP system has accepted an order.

If the seller must provide a confirmed order number while the buyer is still on the phone, an immediate request may be appropriate. The seller waits for the ERP response and can tell the customer whether the order was accepted. The drawback is that the sales task now depends on the ERP system responding promptly.

If a confirmed order number is not needed at that moment, Salesforce could publish an event after the opportunity is won. The ERP system creates the order and sends the number back later. The seller can continue working. The screen, however, must show that order creation is pending. Otherwise, someone may promise delivery for an order that has not yet been accepted.

Salesforce documents an opportunity-to-order example that uses an event and a later response from the ERP system. The example makes an important business distinction visible: a sale recorded in one system and an order accepted in another are separate steps.

Now ask what happens when the ERP system rejects the order because a product code is missing. Does the seller see a useful message? Does an operations team receive a task? Can someone correct the record and try again without creating a duplicate? The integration design is incomplete until those questions have answers.

The moment an integration fails

Successful transactions tend to disappear into the background. Failed ones reveal how much thought went into the design.

A temporary outage is different from bad data. If an application cannot be reached for a minute, trying again may solve the problem. If an order lacks a required address, another identical attempt will fail for the same reason. A system should make that difference clear and route the second case to someone who can correct it.

Retries bring another risk. Imagine an order request reaches the ERP system, but the response back to the CRM platform is lost. The CRM platform may assume the request failed and send it again. Without a way to recognize the original request, the ERP system could create two orders. A unique transaction identifier and checks at the receiving end can help prevent that outcome.

Microsoft’s reliability guidance covers controlled retries, queues, and ways to compensate for an earlier step when a longer process fails. The practical lesson for a business team is simpler: agree in advance how work will continue, stop, or be repaired when one step does not complete.

Give the exception a named owner. “IT will look at it” is rarely enough. Someone should know where to see the failed transaction, what the business user will see, when to involve the source-system team, and how to confirm that the correction reached every affected application.

One revealing test is to take a real transaction and interrupt it deliberately in a test environment. Turn off the receiving connection. Send the same request twice. Change the customer address halfway through. If the team cannot explain the result, the process needs more work before launch.

A fast answer can still be the wrong answer

Suppose the CRM platform defines an active customer as anyone with an open opportunity. The finance system defines an active customer as an account with a posted invoice in the past year. Both definitions may serve their teams. They cannot be swapped without explanation.

The same problem appears in less obvious fields. Does “available stock” exclude goods already reserved for another customer? Does “order complete” mean packed, shipped, or delivered? Which system owns a changed delivery address after an order has been placed?

Before moving important data, record its meaning, source, owner, and permitted uses. Decide which application can change it and what should happen when values conflict. Send only the fields needed for the task. An application requesting a shipping update does not need the entire customer record.

SAP Integration Suite offers ways to connect SAP and third-party systems through application integration, APIs, events, and other forms of exchange. Those tools can carry the information, but people must still agree on what it represents.

Access needs similar care. A system that can read an order status may not need permission to change an order or retrieve payment details. NIST’s zero trust guidance supports making access decisions explicit rather than trusting a connection merely because it sits within the organization’s network.

Measure what the connection changes

A technical team may report that nearly every message was delivered. That is useful, but it may hide the business problem. The few missing messages could be the orders that missed a shipping cutoff.

Measure both the exchange and its effect. On the technical side, track how long updates take, how many fail, how many require a retry, and how long exceptions remain unresolved. On the business side, track outcomes such as time from won deal to accepted order, manual corrections, missed shipments, and customer inquiries caused by an outdated status.

Take a baseline first. If order creation currently takes an average of two hours and requires ten manual corrections a week, write that down. After changing the process, compare the new results with the same measures. Faster delivery matters when it gives someone time to act or removes work they previously had to do by hand.

Where possible, show users when data was last checked. An inventory figure with a visible update time is more useful than one that looks current but may be hours old. A morning report should state its cutoff. People can make sensible decisions with delayed information when they know it is delayed.

Where to begin

Choose one journey that is causing a problem people can describe: an order that misses shipment, a service agent who cannot see delivery status, or a finance team that repeatedly repairs mismatched records.

Follow that journey across applications. At each handoff, ask who needs the information, when they need it, which system owns it, and what happens if it does not arrive. Some exchanges may need an immediate answer. Others may work better as events or scheduled transfers. A mixed design is normal.

Then test the difficult cases with the people who will handle them. A seller should understand what “order pending” means. An operations colleague should know where a rejected order appears. A manager should know whether a report reflects this morning’s transactions or yesterday’s.

The work is complete when the business can rely on the process, including when a system is having a bad day.

How Infonikka can help

Infonikka can help teams map the handoffs between SAP, Salesforce, and other enterprise applications, then choose an exchange pattern for each business need. That includes agreeing on data ownership, deciding how failures will be handled, and giving users a clear view of transaction status.

The first conversation can begin with one question: Where is information arriving too late, or arriving without enough trust to use it?

Explore Infonikka’s system integration services or contact info@infonikka.com to discuss that process.

Glossary

Term	Plain-language meaning
API	A defined way for one application to ask another for information or request an action.
Asynchronous exchange	A system sends work onward and continues without waiting for the final result.
Batch transfer	A group of records moved together at a scheduled time or interval.
Data freshness	How recently information was updated or checked against its source.
Event	A notice that something happened, such as an order being placed or a shipment leaving.
Idempotency	A way of ensuring that sending the same request again does not create the same business result twice.
Latency	The time between a change happening and another system receiving or using it.
Source of truth	The system or agreed owner responsible for the official value of a piece of information.
Synchronous exchange	A system makes a request and waits for the answer before continuing.

References

1. McKinsey, Rewired to Outcompete. Data preparation estimates for AI solution development.
2. BCG, Seven Questions for a Smarter Applications Strategy. Survey findings on integration and application choices.
3. Deloitte, Valuing Data Assets. Finding from Deloitte’s 2025 Tech Value survey.
4. Salesforce Architects, Integration Patterns. Guidance on immediate, asynchronous, batch, and virtual integration.
5. Microsoft, Reliability Design Patterns. Guidance on retries, queues, and recovery.
6. SAP Integration Suite. SAP and third-party integration capabilities.
7. NIST, Zero Trust Architecture, SP 800-207. Access-control principles.