When Business Systems Disagree: A Decision Guide for Reliable Integrations

The visible symptom is rarely the integration problem

A team usually notices an integration when someone is re-entering information, a customer status is wrong, an invoice does not match an order, or two systems show different versions of the same record. The request then becomes: “Can these systems sync?”

That is a useful starting point, but it is not yet a design. Two systems can exchange API calls and still create duplicate records, overwrite a valid change, conceal a failed delivery, or leave staff to reconcile differences in a spreadsheet. The important question is what business event must move, which system is allowed to decide its value, and what should happen when the exchange is incomplete.

Start with an event, not an application pair

“CRM to ERP integration” describes a system pair, but not the work. A more useful starting record names the event, the record, the consequence, and the owner. For example:

• Event: a quote becomes an accepted order.
• Records affected: customer, order lines, tax details, credit status, and fulfilment status.
• Operational consequence: an incorrect or duplicate order can create an incorrect invoice or fulfilment action.
• System-of-record decision: the CRM may own commercial context while the ERP owns the order and financial state after acceptance.

This framing prevents a common failure: treating every matching field as bi-directional. Two systems can each have a customer_status field without each being entitled to overwrite the other. Ownership can be split by record or field, but it needs to be explicit.

Three implementation paths—and the questions that select them

There is no default winner between a maintained native connector, an integration platform as a service (iPaaS), and custom middleware. The proportionate choice depends on the workflow, interfaces, failure consequences, and who can operate the result.

A hybrid can also be sensible. A standard connector may handle a low-consequence reference-data sync, while a separate integration service handles a transaction that needs an explicit delivery record and reconciliation process.

Design for disagreement, not just delivery

A delivery that returns success is not proof that the receiving system contains the intended state. Providers can apply updates asynchronously, reject a field after an initial acknowledgement, impose rate limits, or change data after an event has been sent. A consequential integration needs a path for answering: “What happened to this record?”

1. Record the exchange: retain an identifier, source, destination, event type, time, and processing state appropriate to the data and retention policy.
2. Protect against repeats: use a provider event identifier or a deliberate idempotency key where duplicate processing would matter.
3. Separate temporary failure from a business exception: a timeout may merit a controlled retry; an invalid account state may require a visible owner and decision.
4. Reconcile on purpose: compare the records or outcomes that matter, identify mismatches, and give someone a safe repair route rather than relying on silent eventual consistency.

The exact implementation varies. A nightly comparison may be enough for a low-consequence reporting feed. A payment, order, inventory, or entitlement change may need tighter controls. The requirement should follow the operational consequence, not a generic preference for “real time.”

A short integration discovery checklist

Before selecting technology, collect enough detail to make the boundary inspectable:

• Which business event starts the exchange, and which records or fields must move?
• Which system owns each consequential field after the exchange?
• What is the acceptable delay, and what happens when a record is missing, duplicated, or stale?
• Which APIs, webhooks, exports, databases, or files are genuinely available, and who controls the credentials?
• Who investigates alerts, resolves exceptions, approves changed mappings, and owns the operating procedure?

If those answers are unclear, beginning with a connector purchase or a custom build can only postpone the decision. A useful first phase may be to map the workflow and define the ownership and failure rules before committing to an implementation route.

What this guide does not decide

This is a decision framework, not a promise that every system pair should be connected or that custom middleware is the answer. A maintained native integration, a platform configuration, a process change, or no integration may be the more responsible option. The right choice needs the actual systems, records, risks, and operating constraints in view.