What to map before connecting two business applications
An integration needs more than an available API. Decide which information should move, which system owns it, and how the team will know when the transfer needs attention.
“Connect these two tools” is a starting point for investigation. A useful integration has a specific job: move an approved record, update a defined set of fields, or tell a person that work is ready for the next step.
Making that job explicit helps avoid a connection that copies everything, creates conflicting updates, or fails without anyone noticing.
Define the transfer
Write down the event that starts the work and the result that should follow. For example, a fictional approved job might create a draft invoice for human review. Approval, draft creation, and invoice issuance are three different events.
List the fields required for the transfer. Include what should happen when a field is missing or invalid. Moving only what the receiving step needs can make the workflow easier to explain and maintain.
Define ownership and matching
Decide which application owns each value. Then determine how the integration identifies the same record in both systems. Names and email addresses can change; a shared identifier may be more appropriate where the applications support one.
Consider the next transfer as well as the first. If the original record changes, should the receiving system update automatically, wait for approval, or preserve its own version? What if the receiving record has already moved into a later state?
These rules belong to the workflow, even when the technology makes several options possible.
Establish the permitted route
Check the applications’ supported integration methods, account capabilities, and access requirements. An available endpoint does not by itself establish permission to use it or to move the information involved.
Prefer a supported route that fits the agreed purpose. For sensitive workflows, establish the authorized information and environment before testing. Fictional examples can help verify the basic behavior without assuming access to real records.
Design the failure path
Ask what happens if a request times out, a service is unavailable, or the same event arrives twice. Decide how to avoid duplicate work, when a retry is appropriate, and what evidence establishes that the receiving step completed.
The team also needs an exception path:
- A visible indication that something needs attention
- Enough context for an authorized person to investigate
- A way to retry or correct the transfer safely
- An owner for unresolved failures
Logs should support that investigation without unnecessarily reproducing private record contents.
Plan for change and handover
Record who maintains the connection, which accounts it depends on, and how to stop or recover it. Application changes, expired access, and staff turnover can affect a workflow after the initial implementation.
Define acceptance using ordinary records, corrections, missing information, and failures. A successful demonstration of one transfer is useful evidence, but it does not establish dependable operation across every case.
Keep the unanswered questions visible
Download the integration planning checklist (CSV) and open it in your spreadsheet application. It lists the decisions above, with space for the agreed rule, owner, verification evidence, and any open question.
Complete it for one proposed transfer using fictional examples. An unanswered permission, matching, or recovery question is a reason to investigate further before implementation. Filling in the checklist records the plan; acceptance checks are still needed to establish how the connection behaves.
If the underlying issue is repeated copying, start with mapping duplicate data entry. Our approach to disconnected business tools connects that investigation to a practical plan.
See Systems Implementation for how a defined improvement becomes a bounded engineering engagement.