Systems integration: stop entering the same data twice
Map ownership, direction, timing and recovery for each data flow before choosing connectors, an integration platform or a custom build.
If staff copy the same customer, job or order into several systems, start by mapping the handover. Identify where the record is created, which facts each system owns and what the receiving team needs to do with them.
A connector can move information. It cannot decide whether sales and finance mean the same thing by “customer”, or which address should win when two teams edit it. Those decisions belong in the design before the connection goes live.
Follow one transaction across the systems
Choose a common transaction and watch the people who handle it. Include the spreadsheet checks, email approvals and corrections that sit outside the official process. Record where work waits and which details are entered again.
For each handover, name the authoritative source for the relevant fields. One application may own opportunity status while another owns invoice balances. Avoid assigning ownership to an entire customer record when different facts need different authorities.
Agree identifiers and matching rules. An email address may be shared or change over time; an account number may only be unique within one entity. The connection needs to preserve those distinctions.
Choose a pattern for the actual need
| Approach | Useful when | Check before choosing |
|---|---|---|
| Native link or existing configuration | The supported workflow already meets the requirement | Field coverage, errors, ownership and upgrade behaviour |
| Marketplace connector | A common system pair and process fit the connector | Matching, visibility of failures and vendor support |
| Integration platform | Several flows need shared monitoring and reusable controls | Who governs and maintains the platform |
| Custom connection | A particular workflow or legacy interface needs engineering | Documentation, change handling and ongoing support |
| Governed data hub | The main need is reporting across sources | Definitions, lineage and the distinction from operational updates |
Immediate updates are useful when the next action depends on a response. Scheduled exchange may be sufficient for a daily report. Choose timing from the business requirement rather than assuming every flow must run in real time.
Write an integration map
Use one row per flow, with additional rows where destinations behave differently. The example below is illustrative.
| Record or event | Authority | Destination and timing | Owner and recovery |
|---|---|---|---|
| New customer details | CRM for agreed contact fields | Finance system after validation | Sales operations reviews rejected matches |
| Completed job | Job system | Finance system for invoicing | Operations resolves incomplete jobs |
| Payment status | Finance system | CRM on an agreed schedule | Finance investigates unmatched records |
Add authentication, data sensitivity, monitoring and interface versions to the working specification. Resolve disputed ownership before automating the flow.
Design for failures and repeated messages
A timeout does not necessarily mean the receiving system did nothing. If the reply is lost after processing, an uncontrolled retry may create a duplicate. Give transactions stable identifiers and define how the receiver recognises work it has already handled.
Retry temporary faults deliberately, with limits and appropriate delays. Invalid business data needs correction, not endless retries. Microsoft's retry pattern explains the distinction between transient faults and failures requiring another response.
Keep an exception queue visible to the people responsible for it. Agree how quickly they investigate, how corrections are resubmitted and how final outcomes are reconciled. Monitoring without an operating owner only produces an unattended list of errors.
Before accepting a flow, demonstrate an invalid record, a temporary outage, a repeated message and a correction. Check who receives the alert and whether they can resolve the case using the available information. Include the situation where the connection is restored but older pending records remain undelivered.
For an accounting or other rate-limited API, check the current vendor's authentication, permissions and capacity documentation. Estimate the calls generated by normal work, a backlog and a full resynchronisation. Fixed limits copied from an older article are a poor substitute for checking the integration you plan to operate.
Pilot one complete flow
Choose a flow with a clear owner and a measurable amount of manual work. Compare the whole process before and after: data entry, checking, error handling and downstream reconciliation. A faster handover is useful only if it does not create more work elsewhere.
The Suntory PepsiCo customer story illustrates a shared reporting foundation across enterprise and operational sources. It is a data hub example, not evidence that every operational system was replaced or synchronised in real time.
If the real decision is whether the underlying platform still fits, start with the core-system and ERP assessment. This guide addresses how to make the connections reliable once that direction is clear.