October 15, 2026 · Faith Forge Labs Editorial Team
Connecting Two Business Systems: What Happens When One Stops Responding?
An integration needs a plan for delays, repeated messages and incomplete work. Decide how staff will see and resolve those exceptions before relying on the connection.
Connecting two systems can remove a tedious handoff. An online order might create a job in an operations tool, or a completed appointment might update a customer record. The important design question is what happens when only part of that handoff succeeds.
A connection that works during a demonstration still needs a plan for delays, repeated messages and unavailable services. You should be able to discuss that plan without reading the integration code.
Decide which system is responsible for each fact
Write down what moves, in which direction and when. Name the system responsible for the original record and decide which changes are allowed in the receiving system.
For a hypothetical order-to-job connection, the ordering system might own the order number while the operations tool owns job progress. If staff can edit the delivery address in both places, agree how the systems resolve a disagreement. “They sync” is not a complete answer.
Start with a narrow handoff. List the required fields, what a successful transfer looks like and what should happen when a required detail is missing. Use fictional test records while the behaviour is being developed.
Ask what a repeated message would do
A sender may not know whether a request failed or whether the reply was lost after the receiving system completed the work. Retrying can therefore repeat an action that already happened. Ask how the integration recognises the same business operation and avoids creating a second job or record.
Provider behaviour differs. Stripe's webhook documentation, for example, describes automatic retries, possible duplicate deliveries and events arriving out of order. Those details are specific to that service; check the current documentation for the systems your business actually uses.
You do not need a particular technical pattern in the brief. You do need an understandable answer to: “If this arrives twice, what will the customer and our staff see?”
Give incomplete work somewhere visible to go
An integration should make unresolved exceptions findable. Agree who sees them, how quickly they need attention and what information is safe to show in an alert. A useful status distinguishes work that is waiting, completed or needs a person to investigate.
- If a service is unavailable, will the operation wait, retry or stop?
- Who can retry it manually, and how is that action recorded?
- Can staff tell whether the receiving record already exists?
- What happens if someone fixes a source record after the first attempt?
- How will the team compare the two systems and identify missing work?
Keep a manual fallback proportionate to the workflow. That could mean an authorised person reviewing an exception list, rather than staff quietly creating their own parallel spreadsheet with no agreed owner.
Test the broken handoff before depending on it
Ask the team to rehearse an unavailable service, a delayed reply, a repeated request and an invalid record in a safe test environment. Check the recovery path as well as the error message. A successful retry should not create a duplicate or hide work that still needs attention.
Reliable integration starts with clear business rules and visible ownership. If you are weighing a connection against a larger rebuild, our modernize, buy or build guide provides the wider decision context. To discuss a specific handoff, begin with the two systems, the task between them and the exceptions staff need to handle.