An integration gives two systems a way to exchange information. The business decision is what should happen next, who relies on it and how somebody will notice a failure. Drawing that route before connecting the apps makes the useful work and the remaining manual decisions easier to see.
Draw the information moving through the business
Choose one event, such as a new website enquiry. List the receiving system, the details it needs and the person who acts on it. Decide which system owns the original record and which systems receive copies or updates. Include attachments and later corrections in that discussion. Copy only the information each destination needs, and agree who can view or change it.
Give each step an observable result. A notification being sent, a record being created and a staff member following up are separate states. Keeping those states clear helps the business locate a problem without treating every missed email as a lost enquiry.
Keep the same reference through the handoff
Gregor Hohpe and Bobby Woolf's Correlation Identifier pattern explains how a reply can be matched to the request that caused it. The practical lesson is to retain a reference as information moves between systems. A person checking the workflow should be able to connect related records without guessing from a name or timestamp.
GitHub's webhook guidance also uses a delivery identifier to recognise events, including redeliveries. Each platform has its own behaviour. Ask which reference survives a retry and how duplicate processing is prevented in the proposed connection.
Reading behind this section: Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns; GitHub Docs
Agree what happens when a step fails
A receiving app can be unavailable or reject an update. Decide where that exception appears, who is alerted and how they can recover it. GitHub documents redelivery as a separate action when a webhook was missed. A successful connection test does not establish every platform's recovery behaviour.
Set a sensible limit on retries and make repeated failures visible. Keep enough information to investigate the affected reference, while giving staff an explanation they can act on. Specify which actions need a person to check the record before processing continues.
Reading behind this section: GitHub Docs
Check one complete route before expanding it
Run a labelled example through the proposed path. Check the source record, destination fields, notification and any attachments. Then examine what happens when a required field is absent or the destination is unavailable. These checks should be planned without disturbing genuine customer work.
Leave the business with a short map and a named owner for the connection. Record who can change permissions or field names, and how a broken handoff is noticed. Add further routes when their purpose and responsibility are equally clear.
Put it to use
A useful check for your business.
- Name the event, record owner and receiving person.
- Keep a traceable reference between systems.
- Define duplicate handling and recovery.
- Test a complete route and document its owner.
The thinking behind this guide
Sources & further reading.
Our practical interpretation, with the references below for the specific principles and further detail.
- Correlation Identifier
A reply carries an identifier that connects it to its request. This pattern does not itself establish delivery, duplicate protection or human follow-up.
- Best practices for using webhooks
GitHub documents event checks, delivery identifiers and redelivery. Other platforms need their own delivery and recovery behaviour checked.
