Business systems integration: plan the handoffs

1. Choose the handoff that releases work

Consider a hypothetical maintenance business. A coordinator confirms a service booking in its customer system. Dispatch assigns a technician. The technician records the visit in a field app, and the customer system receives the outcome. These are illustrative roles and records, not a claim that any named products connect this way.

Start with “confirmed booking becomes a dispatch job”. Define what confirmed means: the service address has been checked, the visit type is known and someone has accepted the requested date. An enquiry should remain an enquiry until those conditions hold.

Set the boundary in writing. This first connection creates a job ready for assignment; it does not promise an arrival time to the customer. If you are still deciding whether integration fits the wider problem, the build, buy or connect guide covers that earlier choice.

A service job crossing system boundaries

2. Give each fact an authoritative record

“Keep everything in sync” leaves an awkward decision unresolved. If the coordinator changes the address while dispatch edits the same field, whose version should reach the technician?

For this example, let the customer system own the agreed service address and booking status. Dispatch owns assignment and visit scheduling. The field app holds the submitted visit report. A supervisor accepts that report before the customer system marks the service complete. These are proposed operating rules to agree with the team.

Keep the booking reference alongside the dispatch job reference. Define how updates identify the existing job and how staff see which booking version it uses. Send the fields the receiving task needs; document the mapping, including what an empty value means. A blank access note should not silently erase a useful instruction.

This is the workflow detail behind the business-systems service: the connection has to preserve the decisions people rely on.

3. Complete a handoff card before building

Copy this card for each boundary. The entries below complete the booking-to-dispatch example. Replace the example decisions with your own, then give the card to the person building the connection and the person who will operate it.

• ·Release condition: a coordinator confirms a booking after checking the service address and visit type. Later amendments follow an update path.
• ·Authoritative fields: customer system owns booking status, agreed address and access instructions; dispatch owns assignment. Record any exceptions by field.
• ·Identity: store the booking reference, its version and the receiving job reference. Repeated attempts for the same creation must refer to the same intended job.
• ·Acceptance evidence: dispatch has stored the job and returned a reference. A message saying “sent” is insufficient evidence of acceptance.
• ·Held-work rule: missing required information stays visible to the coordinator. Temporary connection failures follow the agreed retry policy.
• ·Correction and replay: the coordinator corrects the booking in the customer system. An authorised operator resumes the transfer after checking whether a dispatch job already exists.
• ·Change rule: cancellation after assignment requires dispatcher acknowledgement; the booking remains visibly awaiting that acknowledgement.
• ·Operating owner: name the role checking held work, its cover, the escalation route and the point at which staff use the agreed manual fallback.

4. Lose the response, then try again

Ask the supplier to demonstrate this failure: dispatch stores the job, but its response never reaches the connection. A second attempt must find or safely reuse the original job. Otherwise a coordinator could see one booking while two technicians receive assignments.

Stripe’s idempotent request documentation provides a specific example. For API v1, supported POST requests accept a key identifying a request; repeating the key returns the stored result once execution has begun. Stripe says keys can be removed after they are at least 24 hours old. A retry after removal can create a new request.

That is Stripe’s behaviour, not a guarantee about dispatch software. Ask how your receiving system handles repeated creation attempts and how long it remembers them. The implementation must cover a manual replay after an extended outage as well as an immediate retry.

Incoming notifications need a similar check. Shopify documents duplicate webhook deliveries and a delivery identifier for detecting them. It also describes periodically retrieving potentially missed data. For your workflow, agree a reconciliation check that compares confirmed bookings with accepted dispatch jobs and exposes missing or unexplained records.

5. Put failed work somewhere a person can act

A connection timeout and an invalid service address need different responses. Microsoft’s retry pattern guidance distinguishes temporary faults from failures unlikely to improve through repetition. It advises bounded attempts, a policy suited to the failure and logging for operators. It also warns that retries can repeat an operation that succeeded before its response was lost.

Apply that distinction to the handoff card. A temporary outage can wait for a controlled retry. An unrecognised visit type needs correction. A booking cancelled after assignment needs a dispatcher to decide what happens to the allocated visit. Repeating the original creation request cannot settle that decision.

Show the operator the affected booking, its current state, the last attempt and the reason work is held. Give them a safe next action. Choose an escalation threshold based on when the business needs to act, such as before dispatch commits the route. Technical logs alone do not tell the coordinator whether to call a customer.

6. Roll out through explicit acceptance gates

Begin with test records and the failure cases above. Then compare what the connection would create with the coordinator’s real work, without allowing it to issue live dispatch instructions. Resolve mismatches before enabling writes.

Move to a limited live group with a named operator reviewing each transfer. Make the manual and automated paths mutually clear: staff must know which path creates the job. Expand only when the team can account for every booking in the group, explain held items and recover a failed transfer without duplicating work.

Agree how to pause further transfers. Pausing cannot undo a job already accepted or recall a technician already assigned. The fallback therefore needs a list of work already transferred and a rule for continuing it manually.

Hand over the field mapping and the handoff cards with the recovery instructions. Name who updates them when either product changes. Fulcrum’s support and handover approach includes agreeing monitoring and ownership after launch; those arrangements need their own scope.

Sources note: the vendor examples come from the official documentation linked above, checked on 14 October 2026. The service workflow, handoff card and rollout gates are editorial recommendations, not measured client results or vendor requirements.