An integration brief should make the intended connection understandable before anyone promises delivery. Begin with one workflow and a named source and destination. Describe what the receiving team needs, rather than assuming that a connection should copy every field. Compatibility, authorised access and third-party restrictions still need technical discovery.
Describe one flow with a clear owner
Name both systems, their purpose and the role responsible for each. Describe the event that starts the flow and the useful result at the destination. State its direction: one-way movement and two-way updates create different questions about ownership and conflicts.
Use a small fictional record to show the intended meaning of each field. Agree which system owns an identifier, which values are required and what should happen when an expected value is missing. Keep patient records, credentials and confidential exports out of the initial website inquiry.
- Name the source, destination and authorised contacts.
- Record the trigger, direction and expected result.
- List only the fields needed for this agreed workflow.
Define successful and unsuccessful examples
Prepare a normal example and at least one missing, duplicate or invalid example. Agree how a team would know that a record arrived once, was rejected or needs attention. A failure message should identify the next responsible role without revealing sensitive content.
Discuss retries, duplicate prevention, permissions and any reconciliation needed after an interruption. These are topics for the technical specification. A named system or an example field map is not a promise that its API supports the proposed behaviour.
Agree the review and handover
The confirmed integration service area can include an agreed data-flow specification, field mapping, a test connection, failure/retry checks and connection documentation. The actual endpoints, dependencies and acceptance examples belong in the written scope.
Before handover, name who administers access, who investigates a failed transfer and who maintains the mapping when either system changes. Record open exceptions and the person accepting the agreed work. Dates, pricing, support arrangements and third-party costs require an approved quotation; the brief alone does not commit either party to delivery.
Sources & scope
A technical planning aid. It confirms neither system compatibility nor permission to access real records.