Who owns the information between systems?

Define authority at the level of the record

Connecting two tools does not resolve which information should take precedence. A customer record may contain billing details, service preferences and a contract status maintained by different people in different systems.

Identify the authoritative source for each field or business event that the integration handles. Define the identifier used to recognise the same entity across systems. A display name or an email address may be insufficient where records change or duplicates already exist.

Record what should happen when the sources disagree. The answer may be a permitted update, a reconciliation task or a decision by the business owner. A connector should not silently invent that policy.

Specify what moves, when and in which direction

Describe the trigger, the data included, the destination and the expected result. State whether the work runs in response to an event, on a schedule or at a person’s request.

For a two-way connection, define how updates are distinguished from the changes generated by the integration itself. Otherwise, a correction can travel back and forth without a clear owner. Consider the order of events and how the implementation detects an older update.

Access is part of this design. Identify the organisation that owns each account, the permissions the connection needs and the process for renewing or withdrawing that access.

Business owner

Defines the meaning of the information and decides how conflicts should be resolved.

System owner

Controls the source or destination, its access and changes that can affect the integration.

Implementation owner

Maintains the connection, its monitoring and the agreed recovery instructions.

Separate an attempted update from a confirmed result

A network request can fail before reaching a system, while a system processes it or after the change has been made but before the response reaches the caller. An error message at one end is not a complete account of the other end.

Define how the integration recognises an accepted update and how it finds the result later. The design may use destination identifiers, stable request identifiers, event records and reconciliation. The appropriate mechanism depends on the interfaces available.

An integration that repeats a request needs protection against unintended duplicate effects. That protection must be implemented and tested for the particular operation; it should not be assumed from the presence of a retry button.

Make unresolved work visible to the right person

An operational view should distinguish waiting work, confirmed completion and items needing attention. Include enough context to identify the source, destination and operation without exposing unnecessary sensitive contents.

Agree who receives an issue, the response expected and how the business can continue while it is unresolved. Some work can safely wait. Other work needs a manual route with a record of what happened outside the integration.

Monitoring and support are different responsibilities. A notification that a job failed is useful only if someone knows what they are expected to inspect and which actions they are permitted to take.

Leave a connection that can be maintained

The handover should describe the data mapping, access dependencies, update rules, confirmation method, known limitations and recovery route. Give the client the operational information and ownership arrangements agreed in scope.

Test examples should include normal updates, changed permissions, duplicate events and interrupted connections. Where a supplier changes its API or the business changes its process, identify which checks need to run again.

The practical result is a connection with an understandable operating model: the data it handles, the changes it is allowed to make and the people responsible when the systems cannot agree.