Use this guide before committing a delivery date or buying a tool that depends on another system. The goal is a short evidence note about one real workflow: what can be tested now, what requires someone else’s decision and what must remain manual. It helps organize the questions; it does not certify a connection.
Go to the copyable integration note
Describe the end-to-end task
Start with the result the person needs, such as a confirmed appointment or an acknowledged order. Name the system where the task begins, the system that must act and what the user can see when it is complete. An API response can confirm receipt without confirming that the business action happened.
List what happens today if the connection is unavailable. That gives you a comparison and a possible fallback. Keep a legitimate human check visible rather than assuming that every step should become automatic.
Check the specific capability and data
- Find the current documentation for the exact operation, product version and account tier. A vendor’s general integration claim is a lead to verify.
- Check whether a suitable test environment, representative permitted records and a responsible counterpart are available. Record unavailable access as a dependency.
- Agree the identifiers, required fields, units, time zones and status meanings needed for this task. Include missing and invalid values.
- Identify which system owns each important fact, who may correct it and how users see a corrected value. Copying a record does not make both systems authoritative.
- Check relevant volume limits, availability expectations and any usage cost against the bounded workflow. Do not infer production capacity from a successful single request.
Establish access and responsibility
Name who approves data use and who can grant the minimum permissions the task requires. Keep credentials out of the worksheet. Use approved storage and access arrangements; do not paste live keys or sensitive payloads into a shared planning document.
Agree who supports each side and who can investigate a failed or uncertain request. If personal or regulated information is involved, obtain the relevant specialist review before using it. This guide cannot supply that authorization.
Make incomplete work recoverable
For one task, consider success, a clear rejection and an outcome whose confirmation is missing. Ask how the system and the responsible person determine whether the action happened. Agree how to match requests to resulting records and how duplicate actions are prevented or detected.
Record whether retrying is safe for this specific operation. If that has not been established, use a reconciliation step rather than blind retries. Define the message the user sees, the person who handles the uncertainty and the manual alternative. Set a practical review point so unresolved work does not disappear into a log nobody reads.
Run a bounded demonstration with the counterpart
Use a small permitted test set. Include a normal record, a missing required value, a denied action and an interrupted or unconfirmed request where the environment permits it. Compare the final state in both systems with the intended result. Record the exact environment/version, expected behavior, observed behavior and remaining gap.
A mock can check your assumptions about a message shape. It cannot prove access to the actual partner system or the behavior of its current operation. If only a mock is available, carry that limit into the commitment.
Worked hypothetical example: an order awaiting acknowledgement
This scenario and its quantities are invented to illustrate the guide. No supplier integration or test result is being claimed.
A small wholesaler wants approved purchase requests to become supplier orders. The initial proposal assumes that a successful HTTP response means the supplier accepted the order. The team’s first question is whether that response confirms receipt, creates an order or provides a later acknowledgement to check.
The proposed demonstration uses three synthetic orders: a normal order, one missing a required product identifier and one whose response is deliberately interrupted in the test environment. A purchasing owner checks the supplier’s final records before any uncertain request is retried. The current manual ordering process remains the fallback, with a record of which requests have already been sent.
If the counterpart can demonstrate acknowledgement, denied access and safe reconciliation, the next decision may be a limited supervised connection. If the team cannot establish whether an order exists after an interruption, it keeps sending manual orders while resolving that dependency. A connection that merely accepts a payload has not yet demonstrated the promised purchasing outcome.
Copy the integration evidence note
Select the text below and copy it into your document. Use placeholders for sensitive details and record the safe location of evidence rather than embedding credentials or customer records.
User task and business completion state:
Starting system, receiving system and their owners:
Current manual route:
Exact operation/version/account capability checked:
Documentation and test-environment availability:
Permitted example data and data-use approver:
Required identifiers, fields, units and status meanings:
System of record and correction owner:
Required permissions and access owner (no credentials):
Success evidence visible in each system:
Rejection behavior and exception owner:
Unconfirmed outcome: how we establish what happened:
Safe retry/duplicate handling demonstrated or unknown:
Fallback and reconciliation of work already created:
Volume/cost/support assumptions still untested:
Expected versus observed behavior and evidence location:
Blocker, responsible person and next evidence:
Proceed / narrow scope / defer, with reason and review date:Separate a test result from a delivery promise
Mark each important dependency as demonstrated, assumed or unresolved. Do not turn the number of completed fields into a readiness score. One unresolved permission or uncertain business action can matter more than many successful field mappings. Choose the smallest next demonstration that could change the decision, or keep the manual route if the connection is not justified.
Use a pilot brief to bound the next demonstration
Read about responsibility after an uncertain cross-app action
Use the interactive companion
The builder follows the guide’s model. Your answers remain in this tab. The complete plain worksheet above remains available without JavaScript.