Questions to answer before connecting business systems

Before connecting two systems, agree which one owns each record and how the connection will recognise a completed action. Access alone is not an integration specification.

Name the authoritative record

A customer may appear in a website form, a sales spreadsheet and an accounting application under slightly different names. Decide which system creates the authoritative identifier and which fields another system may change. Matching on a name alone can create ambiguous updates.

Write a field ownership map. For example, a workflow might read the approved supplier account from one system while sending a purchase reference to another. That does not give it authority to change the supplier’s payment details. Be specific about direction, fields and permitted actions.

Prepare an interface worksheet

Requirement	Evidence to request
Supported route	Current API or connector documentation for the intended operation.
Access	Named account or application identity and the minimum required permission.
Identifiers	Stable keys used to distinguish new, existing and duplicate records.
Limits	Relevant usage, size, timing and licence constraints.
Failures	Timeout, rejection and unavailable-service behaviour.
Ownership	Who maintains each side and handles changes or expired access.

A vendor logo in a proposal does not prove every required operation is available. Verify the actual interface and entitlement before accepting the integration scope.

Test ambiguity at the destination

Imagine a request reaches the destination but the response is lost. The sending workflow sees a timeout; the destination may already have created the record. A safe retry needs a stable request identifier or another supported way to reconcile the result.

The exact mechanism depends on the destination. Ask the implementer to explain how duplicate writes are prevented and how uncertain outcomes are surfaced. Do not accept “we retry on error” as the complete design for consequential actions.

Plan a useful test environment

Use an authorised test route with synthetic or appropriately controlled sample data. Confirm what is isolated and what still reaches a real external service. A test-labelled account is not sufficient if it can still trigger real notifications, financial activity or customer changes.

Agree normal, invalid, duplicate and interrupted cases. Record the source case identifier and the corresponding destination result so a business reviewer can verify the handoff without examining confidential technical logs.

Hand over the dependency, not just the connection

• Document the account owner and renewal or expiry route.
• Record configuration locations without exposing secrets.
• Identify an alert owner and a reconciliation procedure.
• Define who reviews vendor interface or licence changes.
• Keep a way to stop new work while preserving pending cases.

An integration is maintainable when the organisation can identify its owner and recover a known failure. A successful one-off transfer is useful evidence, but it is only one acceptance case.