Integration planning starts with the handoffs

When somebody asks whether two systems can connect, the technical answer is only part of the product decision. The more useful question is what needs to happen across that connection, who depends on it, and how they will know when something has gone wrong.

A connection can move data successfully while leaving the workflow confused. One system may describe a job as complete while another still treats it as active. A person may retry an action because the confirmation is unclear. An operations team may receive a record without the context required to act on it. Integration planning should make those handoffs visible before they become somebody's daily workaround.

Follow one piece of work through the product

I would begin with a recognizable unit of work: a customer inquiry, an invoice, an estimate, or an event promotion. Then I would follow it from the moment it enters the process to the point where somebody considers the job finished.

The Workhorse concept provides a useful example. It connected estimates, jobs, scheduling, invoices, expenses, and client communication around a contractor's workflow. My contribution involved product direction, scope, sequencing, and coordination with design and engineering. The outcome was a defined concept and initial scope, rather than a claim that every connection was implemented.

Thinking through the lifecycle of a job changed the product conversation. An accepted estimate is meaningful because it should lead to work being scheduled and completed. If those steps require people to recreate the same information, the product has preserved much of the original fragmentation behind a new interface.

Decide which system owns the answer

Connected systems often contain similar information for different reasons. A contact name may appear in a marketing tool, a scheduling system, and an operational record. That does not mean all three should be able to change the same fields without an agreed rule.

From a product perspective, I want to know where a person should make a correction and how the correction reaches everyone else who needs it. The engineering team can assess synchronization approaches and technical constraints. Product and operations need to define the intended ownership and the consequence of stale information.

Imagine a customer changes their preferred contact method. Does the change apply to every kind of communication? Does an existing task preserve its original instructions? Is the person making the change allowed to affect all related records? These are policy and experience questions as well as implementation questions. A field mapping alone cannot settle them.

Status needs a shared meaning

A label such as complete can hide several states. An action may have been requested, received, validated, or carried out. Those stages may happen at different times. If the interface collapses them into one reassuring message, the person using the product may act on an assumption the underlying systems cannot support.

At MessagePay, the product paired a borrower-facing payment flow with institutional controls, visibility, and reporting. My role focused on product direction, stakeholder alignment, and coordination with design and engineering. The work illustrates why a simple front-end action still needs an operationally useful account of what happened behind it.

For a hypothetical integration, I would write the status definitions in plain language before choosing their labels. What can the user safely do at this stage? What remains outside the product's confirmation? The goal is to communicate the state accurately without forcing the user to understand the implementation.

Plan the interruption, not just the transfer

An integration conversation should include what happens if the next system does not respond. The engineering details may involve timeouts, queues, or retries. The product consequence is that a person needs to know whether to wait, try again, or ask for help.

I would work with engineers to identify the cases that could create duplicate or conflicting work. Then we can decide which actions the interface should allow and what evidence an operator needs to investigate an issue. A failure message should be tied to a useful next step, rather than merely acknowledging that a problem exists.

The Google SRE book's monitoring chapter distinguishes internal system signals from checks of externally visible behavior. That distinction is helpful in product discussions too. A service can appear healthy while a particular workflow is failing. The team needs a way to recognize the experience people actually receive.

Keep operational ownership in the scope

Somebody will receive the question when a connection does not behave as expected. If the team has not identified that person or group, the work may bounce between departments while the user waits.

For a proposed integration, I would ask who investigates a delayed record, who can correct it, and what information they are permitted to see. A support view may need different details from a customer-facing view. Those requirements belong in the initial scope if they are necessary to operate the workflow responsibly.

This was part of the broader challenge in Spera, where clients, projects, time tracking, invoicing, and payments formed a connected experience. I worked across requirements, design, team leadership, release planning, and ongoing maintenance. A decision about one part of the workflow could affect what another part needed to display or explain.

AI can propose a mapping, but it cannot settle responsibility

AI could help compare field names, summarize interface documentation, or draft questions for an integration review. I would treat that material as a starting point. Similar names do not prove that two fields mean the same thing, and generated explanations can miss constraints that matter to the organization.

If I were using AI for this work, I would supply approved documentation and ask it to identify uncertainty rather than silently fill gaps. The review would involve the people who understand each system and the people accountable for the workflow. Sensitive operational records would not be a casual substitute for carefully prepared examples.

The useful output might be a short list of unresolved definitions. That can be more valuable than a polished mapping document because it tells the team where a decision is still required before implementation can proceed.

Validate the handoff as a whole

Before accepting a connection, I would walk through the full scenario with engineering and the affected operations team. The test should include a normal transfer, a correction, and an interruption. We need to see whether each person can understand the state and complete their next task.

The level of detail should fit the consequence of failure. A nonessential display update and a payment-related action deserve different release discussions. The team should make that distinction consciously rather than applying the same checklist without context.

Integration planning is successful when the resulting workflow is understandable and supportable. The systems may be doing sophisticated work behind the scenes, but the people relying on them should have a clear account of what happened, what comes next, and who can help when the handoff needs attention.