Start with the Workflow, Not the Connection
The useful question is not simply whether two systems can exchange data. It is what people are trying to complete, where information becomes duplicated or lost, which system owns each fact, and where a person needs to review a decision.
Map one bounded workflow from trigger to outcome. Record the normal path, the exceptions and the people affected. That makes it possible to choose the smallest useful connection and define what success looks like before any software is built.
Choose the Authoritative Source for Each Record
Every important item should have one clear source of truth. A CRM may own the customer record, an accounting platform the invoice, and an operations tool the fulfilment status. The integration should move the information required for the next action without creating competing master copies.
- Define which system creates and owns each identifier.
- Decide which changes may flow in each direction.
- Prevent repeated events from creating duplicate records.
- Preserve timestamps and audit context needed to understand a change.
Use the Safest Maintainable Connection
Supported APIs and webhooks are normally the strongest starting point. Where those are unavailable, a controlled export, import, document process or human-assisted tool may be more reliable than brittle browser automation. The design should account for authentication, rate limits, provider changes and the consequences of a delayed or repeated event.
Keep Important Decisions Visible
Automation is useful for predictable movement and validation. It should not conceal a consequential decision. High-impact changes can require confirmation, while routine safe actions can proceed automatically with a clear audit record and an understandable route for correction.
Build for Failure and Recovery
Real systems become unavailable, credentials expire and data sometimes fails validation. Production integrations need health monitoring, useful alerts, safe retries, duplicate protection and a way to inspect what did not complete. Backups and recovery arrangements should be designed with the service rather than added after launch.
What a Focused Integration Does—and Does Not—Do
It connects a defined workflow across existing systems. It does not make unsupported platforms reliable, remove the organisation's responsibility for lawful data use, or justify replacing software that already works. When the evidence shows that a small tool, clearer process or no build at all is the better answer, that should remain an available outcome.
Tell OpsHarbour about the workflow or return to the bespoke software service overview.
Frequently Asked Questions
How can a business connect systems it already uses?
Start with one defined workflow, identify the authoritative system for each piece of information, then use supported APIs, webhooks or controlled data exchange to move only what the workflow requires.
Do connected systems need to be replaced?
Usually not. A focused integration should preserve systems that already work and add only the missing connection, visibility or decision step.
What if one system has no API?
The options may include supported exports, controlled imports, email or document processing, or a small human-assisted tool. The safest maintainable route depends on the system and the importance of the workflow.
How do you prevent an integration from creating bad data?
Use validation, idempotency, clear ownership rules, audit records and human confirmation at decisions where an incorrect change would matter.
Can OpsHarbour monitor and support an integration after launch?
Yes. Production operation can include health monitoring, failure alerts, encrypted backups, documented recovery and planned maintenance where appropriate.