Skip to main content

Automation · 6 min read

When Business Systems Do Not Agree: Integration That Survives Operations

Duplicate entry, mismatched addresses, and APIs that look fine in a demo. How to choose ownership, connection method, and where people still approve.

August 18, 2024Written by Oscillate Infotech Team
All insights
Interface exampleReporting console showing consolidated output by line, a validation log and automated report distribution

CRM shows one ship-to address. The warehouse ships another. Finance invoices a third. That is not an abstract “data quality” problem - it is a customer call and a leadership slide with two revenue numbers. Most of that damage comes from the same fact living in several tools with nobody named as owner.

What disconnected systems actually cost

People re-type the same customer, order, or SKU into CRM, accounting, and a shipping portal. Typos and unit-of-measure mistakes travel with them. Someone maintains a spreadsheet “bridge” that only they understand. When tax rules or a product code changes, three places need edits and one is missed.

The useful integration project starts from one painful handoff that happens many times a week - not from a diagram that connects every system on day one.

When manual transfer is still reasonable

Leave the process alone if volume is low, mistakes are cheap to catch, and the person doing the copy understands both systems. A weekly export that a supervisor checks before posting can be safer than a half-built sync that silently doubles invoices.

Automation earns its keep when the same handoff produces regular errors, burns hours, or breaks under load. Frequency and consequence matter more than whether an API exists.

Integration, APIs, synchronisation, and automation are not the same

These words get used interchangeably. They should not.

System integration is the business design: which systems participate, what moves, and who wins when they disagree.

API development is building or exposing a contract - “send this, get that, here is the error shape” - so partners or internal tools do not scrape screens. An API can exist and still be useless for integration if it cannot express your real statuses, rate-limits you into batch reality, or lacks write semantics you need.

Workflow automation is triggering steps when something happens: create the shipment after payment clears, notify ops when stock fails validation. It may call APIs; it is not the same as “we have an API.”

Data synchronisation is keeping copies aligned. Sync without ownership rules is how you get fighting updates and duplicate customers. Two systems holding the same field does not mean both should control it.

Decide who owns the data before you write code

Pick one system of record per entity - or per field, when that is honest. Example: ERP owns customer credit and legal name; CRM may hold the sales notes and own the pipeline stage. Ship-to address has one winner; everyone else gets a read-only copy or a controlled propose-change path.

Agree mismatch handling up front: reject, queue for a human, or overwrite with a logged reason. If that conversation has not happened, development will invent answers under deadline pressure and operations will pay later.

An available API does not make the job simple

Vendor APIs omit edge statuses your warehouse uses. Tokens expire. Rate limits force you into batches even when the sales pitch said “real-time.” Schema changes ship with little notice. Auth scopes are wrong for the write you need. Sandboxes that do not mirror production lie to you until go-live.

Treat the first useful endpoint as narrow and preferably read-only - “order status by ID,” “stock for a SKU list” - with authentication, structured errors, and documentation a partner can use without ten support calls. Prove reliability before opening writes.

Choosing how to connect

There is no single correct pattern.

Direct API-to-API fits when both sides are stable, volumes are moderate, and you can own retries and mapping in one place.

Middleware or an integration service helps when many systems meet and you need central logging, mapping, and replay - at the cost of another moving part to operate.

Scheduled import/export (CSV, XML, JSON drops) is underrated. Nightly or hourly batches are often enough for inventory snapshots or accounting postings. They are easier to reconcile and easier to pause.

Database-level links or shared tables are fast and brittle; schema coupling and permission risk make them a last resort except inside a tightly controlled estate.

Event-driven or webhook flows suit status changes that must propagate soon - shipment shipped, payment failed - provided you design for duplicates, out-of-order delivery, and downtime on the receiver.

Controlled manual approval steps belong in the design: credit hold releases, odd pricing, first-time vendors. Removing the human from those paths is how automation creates expensive mistakes.

The failure paths matter more than the demo

Happy-path demos hide what operations hits weekly: partial failures (order created, invoice not), duplicate posts from retries without idempotency keys, conflicting updates when two systems think they own the same field, auth expiry at 2 a.m., rate-limit storms, upstream schema changes, and no audit trail of what the integration changed and why.

Build for reconciliation reports, dead-letter or exception queues, monitoring that pages a named owner, and recovery you have rehearsed. Rollback or replay must be possible. If you cannot explain what happens when the warehouse API is down for an hour, you are not ready to cut over.

Keep judgement where it earns its keep

Automate the repetitive, validated path. Leave exceptions for people: mismatched units, credit edge cases, one-off customer terms. A practical first slice looks like validated capture into one system of record, status pushed outward, humans clearing a daily exception list - not a promise that nobody will touch an order again.

Introducing integration without freezing the business

Start with one object and one direction of truth. Log mismatches. Run a weekly reconciliation until error rates are boring. Expand to the next object only when the pattern is trusted. Parallel-run or shadow mode beats a Friday big-bang. Peak season is a bad time to invent new failure modes.

Real-time sync costs more to operate than scheduled transfer. Use it when delay creates real commercial damage - not because the architecture slide looked better.

How we approach this at Oscillate Infotech

We start from the handoff that hurts and the ownership argument - not from a catalogue of connectors. That usually means mapping systems and fields, choosing a first slice, deciding API vs batch vs hybrid, and designing exception handling before coding the happy path.

Integration, API work, and workflow automation on our services list are the same discipline: make one fact authoritative, move copies deliberately, and keep people in the loop where judgement matters. A short written look at one flow - where duplicates and mismatches appear today - is enough to decide whether to automate, schedule, or leave the manual step alone.

Continue reading

View all insights

From insight to implementation

Need a clearer path through a software or automation decision?

Talk through your project