Why Connecting Two Systems Still Requires Business Rules

Two systems can exchange information perfectly and still disagree about what it means. One may call a sale complete when a quote is accepted; another may wait for payment. A connection needs business rules for timing, ownership, corrections, and exceptions. Without them, automation can spread ambiguity more quickly than manual entry.

Define the event behind each status

Ask staff what must happen before a record reaches a given stage. Does 'approved' mean a manager signed off, a customer agreed, or a payment cleared? Write the definitions in plain language and decide which system is authoritative for each event. If the terms differ, keep separate statuses rather than forcing a single label. A developer can map values only after the business says what each represents.

For a hypothetical retailer, a sales system marks an order ready when the customer accepts a quote, while the warehouse uses ready to mean stock has been picked. Copying that status automatically could prompt premature dispatch. A good rule would send the accepted order as a new task and let the warehouse record its own readiness. The distinction prevents a customer promise from being confused with an operational fact.

Agree what happens when information changes

Which system owns a customer's address, and does an update affect open orders or only future ones? Can a manually corrected quantity be overwritten by a late message from the source? What if a customer appears twice? Set rules for ordinary changes and identify cases that require review. A conflict should be visible to someone responsible, not resolved by whichever update happens to arrive last.

The GOV.UK service standard on common components and standards recommends authoritative sources of data where possible. Its public-service context differs from a private firm's, but the idea helps: decide where each fact is maintained, then make dependent tools respect that ownership.

Plan for delay and failure

An outside connection can be unavailable or send an update later than expected. Decide whether work should pause, proceed with a clear pending state, or use a manual check. The GOV.UK guidance on APIs notes that third-party failure may require a delayed action, alternative route, and clear communication. Use the response that fits the business consequence rather than a universal rule.

Test normal and awkward cases with staff from both sides. Check what each sees, who can repair a mismatch, and whether the customer receives an accurate answer. A successful technical message is not enough; the receiving system must accept the fact in the intended meaning. Keep a short record of the rules so later changes do not undo the agreement.

Decide how corrections propagate. If a customer changes an address after a delivery label was printed, updating the customer profile may not be enough. The responsible person must know whether the shipment can still change and whether the customer was informed. The integration should reflect that sequence, or clearly signal that manual action is required. A rule about data becomes a rule about work once people act on it.

Review conflicts after launch. If the same kind of mismatch appears often, the original definition may be incomplete or staff may have found an exception that was not considered. Ask the teams to describe the case before changing the mapping. A revised business rule can then be implemented and tested against past examples, reducing the chance of fixing one screen while breaking another.

Holism can help an owner turn these decisions into a clear workflow while a developer uses AI and reusable capabilities to implement the transfer. The business defines meaning and authority; the developer handles safe delivery and visible errors. Systems work together when their rules match the work people actually perform.