Business integration guide

How do you stop re-entering data between business systems?

Stop duplicate entry by deciding which system owns each business fact, how changes cross the boundary and how failed or repeated updates are reconciled. Integration is complete only when the receiving outcome is verified.

Discuss the integration Jump to data ownership

Published 28 August 2026 · 11 minute read

The practical answer

Choose one authoritative system for each business fact, capture or approve the fact in the workflow that owns it, and send a stable business message to other systems through a supported API, event, queue or batch interface. The receiving system should validate identity and version, apply the change safely, return or record an outcome, and expose failures for retry or correction.

Do not begin by synchronising every field in both directions. Begin with one valuable change and a clear ownership boundary.

Decide which system owns the fact and which consumes it

Question	Why it matters
Where is the fact created?	Identifies the workflow with the strongest context and validation
Who may correct it?	Prevents competing edits and silent overwrites
Which identifier is stable?	Allows systems to refer to the same customer, order or case
Who needs a copy or view?	Separates operational use from unnecessary duplication
How fresh must it be?	Determines immediate, asynchronous or batch exchange
What proves completion?	Defines acknowledgement, reconciliation and support ownership

Sometimes the right answer is a read-through view or link to the owning system rather than another stored copy.

Choose the smallest integration pattern that fits the timing

API

Immediate request and response

Use when a person or process needs a current answer before continuing.

Event or queue

Durable asynchronous change

Use when systems may process independently and temporary delay is acceptable.

Batch

Controlled periodic exchange

Use for bounded volume, reporting periods or systems with file interfaces.

RPA

Constrained screen bridge

Use when no supported interface exists and monitoring can manage interface fragility.

Compare APIs, webhooks and queues in more detail, or design a broader business system integration layer.

Transfer business meaning, not a loose set of fields

define the business event or command in plain language;
include a stable source record and message identifier;
specify required and optional fields, units, codes and time zones;
version the contract and define compatibility expectations;
separate create, update, cancel and correct operations;
state which validations belong to the sender and receiver; and
avoid exposing internal database columns as a public contract.

A useful contract might say “customer contact details were verified” or “order 123 was approved at version 4”, not merely transmit a row whose meaning depends on another system's schema.

Design for partial failure and repeated delivery

AWS describes the transactional outbox pattern for avoiding a dual-write gap between a database change and an event notification. It also notes that consumers should be idempotent because messages can be delivered more than once. Azure similarly describes idempotency as a resilience strategy for safely repeated operations.

Commit the source change and an integration work record together where appropriate.
Deliver the message with a stable identifier and traceable correlation ID.
Make the receiver safe to retry without creating another business outcome.
Record success, rejection, temporary failure and permanent failure separately.
Retry only recoverable failures with backoff and an upper bound.
Move unresolved work to a visible exception queue with an owner.
Reconcile source intent against receiving-system state.

Remove one repeated entry path end to end

Baseline duplicate entry→Define ownership→Choose contract→Implement and reconcile→Retire manual entry

measure volume, handling time, corrections and downstream impact;
collect representative creates, updates, cancellations and duplicates;
prototype the weakest source-system interface first;
run controlled parallel verification before removing manual entry;
train staff on exception handling rather than keeping a hidden workaround; and
monitor update success, latency, duplicates and reconciliation differences.

Avoid creating a harder synchronisation problem

do not make both systems authoritative for the same editable fact;
do not use direct database writes into a product you do not own;
do not treat a successful HTTP response as proof of the business outcome;
do not retry a non-idempotent create without a stable key;
do not discard rejected records or integration errors;
do not synchronise sensitive fields merely because they are available; and
do not remove the manual process until exception ownership is operating.

Use reconciliation workflow automation when the central need is proving that two record sets agree.

Sources

Primary references