The connection guide
Before you join
two systems.
Write a small connection contract. It should tell a reviewer what moves, who permits it, how completion is checked and what happens when the transfer cannot finish.
A reliable handoff has a stable reference, approved information, a defined action and a visible outcome. A person needs to own the work that pauses or fails.
1. Name the start and finish.
Describe the event that begins the workflow and the result that means it is complete. “An approved booking creates a preparation task” is a clearer boundary than “connect our booking system and project board”. State which events should not begin work.
2. Define the source of truth.
List where each required field comes from. Decide what happens when a value is absent or two sources disagree. The workflow should ask for a check rather than silently choosing a plausible value.
3. Separate the permissions.
Reading a record, preparing a draft, sending a message and updating a system are different actions. Write down which actions are allowed and which need approval. A person should be able to inspect what is proposed before the agreed commitment occurs.
| Trigger | Which verified event begins this process? |
|---|---|
| Reference | How will the source and destination item be matched? |
| Information | Which fields are required and where do they come from? |
| Authority | Who can approve the proposed action? |
| Completion | What evidence shows the intended change happened? |
| Recovery | Who can find, check and resume unfinished work? |
4. Test a repeated event.
Many systems can deliver an event more than once. Check how the workflow recognises work already processed. If the match is unclear, make the review visible. A repeated request should not silently create another booking, task or message.
5. Test a failed destination.
Plan for timeouts, access changes and unavailable systems. Keep a record of the intended action and its state. Before retrying, check whether the destination already accepted the change. Recovery should not turn uncertainty into duplicate work.
6. Give the owner a practical view.
The person running the workflow needs to distinguish completed work, work waiting for approval and work waiting for recovery. Agree how they are notified, what they can change and when to stop the automation for investigation.
7. Review information and tool access.
Confirm that the tools and account permissions suit the information involved. Use fictional or redacted records while the process is being scoped. Check access, retention and the people or services receiving the information before running a trial with real records.
Try an exception
Rehearse the recovery route.
ILLUSTRATIVE FAILURE MODE
Hold the incomplete item.
A required reference is missing. Keep the original request, mark the missing field and send it to the process owner. A person verifies the detail before an update is attempted.
Resume from the checked item. Do not invent the reference.
A practical first connection
Bring the handoff
that keeps breaking.
We can start by mapping the work and its exception route.