The short answer
An integration brief should describe the business event, source and destination systems, data ownership, supported interfaces and expected failure behaviour. Include examples of real records and define how the result will be checked.
Describe the event and the action it should trigger
Start with a business event: an appointment changes, an order is paid, a sensor reports an exception or a case is approved. State what another system or person needs to know next.
Specify how quickly the update is needed. A daily reconciliation report and an operator alert have different requirements; “real time” should describe an operational need rather than a default preference.
Define the records and the source of truth
List the fields that need to move and what they mean. Include identifiers, status values, time zones, units and sample records with sensitive information removed.
Assign ownership when two systems can edit the same record. Decide which value wins, when a conflict requires review and how a correction should be propagated.
Inventory the supported interfaces
Collect API documentation, export formats, authentication requirements and vendor contacts. Confirm access terms and whether a test environment is available.
An integration plan based on an assumed interface is an untested dependency. If documentation is incomplete, set aside a discovery step to verify what can be connected reliably.
Plan for failure and recovery
Discuss unavailable systems, duplicate messages, partial updates and delayed records. Define retries, reconciliation and the point at which a person needs to intervene.
Decide who receives an alert and how they investigate it. A failure log is useful only when someone can understand the event and take the next action.
Agree acceptance and operating ownership
Use representative records and exception scenarios to confirm the integration works. Include permission checks and recovery scenarios alongside the successful path.
Name the team responsible for credentials, monitoring, vendor changes and ongoing support. Document the connection so it can be maintained after the original project ends.
Your planning checklist
- Business events and required response time
- Systems, owners and vendor contacts
- Sample records and field definitions
- Authentication and test access
- Failure, reconciliation and support procedures