The starting point
An integration can look like a simple line between two applications. The useful questions sit behind that line: what information is being exchanged, when it should move, who can change it and how the team will recover from an incomplete handoff. Start with those decisions before treating the connection as a technical task.
Follow one record through the workflow
Choose a realistic example, such as a customer request moving from a portal into an internal workspace. Describe where it begins, which information it needs and the people who act on it. Trace later changes too, including corrections, cancellations and status updates.
Mark the steps that are currently manual and why they exist. Some may be unnecessary copying; others may be important review points. Connecting the applications should not silently remove a decision that someone still needs to make.
Agree who owns each piece of information
Decide which system is authoritative for each important field and where changes are permitted. One application might own contact information while another owns the status of a service request. Avoid assuming that ownership has to sit in the same place for every part of a record.
Agree how records will be matched, what counts as a duplicate and how conflicting changes will be resolved. Use language that the business team can review. If two systems describe the same status differently, that difference needs a decision before it becomes a mapping rule.
Design the interrupted handoff
Walk through what happens if information is missing, a destination is unavailable or the sender cannot tell whether a change was accepted. Decide which situations can be retried, which need review and what the person using the application should see while the handoff is unresolved.
Include repeated requests in the design conversation. If the same action is sent again, the team needs to know whether it updates existing work or accidentally creates another item. Agree how the applications identify the original action and how someone can investigate an uncertain result.
Make support part of the scope
Give the connection an operational owner, not just an implementation owner. Agree how the team will notice unresolved work, what information is useful for investigating it and who can authorise a correction. Review access to diagnostic information so troubleshooting does not expose more data than necessary.
Before release, test ordinary updates, rejected records and interrupted handoffs in a suitable environment. Agree how changes to either application will be reviewed later. A connection becomes part of an ongoing business process, so its support plan belongs in the original brief.
Put the thinking into practice
Ready for your next step?
