Name the business result of the connection
“Connect the CRM and ERP” names two systems, but it leaves the job undefined. Should an approved customer appear in both? Should an order create a fulfilment task? Should managers see a combined report? Each result requires different information, timing and responsibility.
Describe one complete journey from its starting event to the outcome a person can verify. Identify the people who depend on it and the manual steps it should replace. Keep the first scope specific enough to test. A list of available interfaces is useful engineering input, but it does not decide which business process the integration should support.
Agree on the meaning and owner of each fact
Two systems can use the same word for different things. “Customer” might mean a billing account in one and an individual contact in another. “Available stock” might exclude reservations in one view and include them in another. Agree on these definitions before mapping fields, or the connection may transfer information correctly while presenting the wrong meaning.
Assign an authoritative source for each relevant fact. One system might own product descriptions while another owns stock quantities. Decide which changes are allowed to flow in each direction and how conflicting edits should be handled. A shared record needs a stable way to identify the same entity across systems; matching by a display name alone deserves particular scrutiny.
Choose timing around the decision it supports
| Use | Timing question | Requirement to define |
|---|---|---|
| Operational action | How old can the information be before the action becomes inappropriate? | An acceptable delay and what happens when information is too old. |
| Management reporting | Which reporting period must the figures represent? | Collection timing, period definitions and a visible freshness indicator. |
| Historical reconciliation | When and how will records be compared? | A comparison window, a way to identify differences and an owner for resolution. |
Describe a failed transfer before the first successful one
For example, the destination might record an order while the sending system never receives confirmation. Repeating the request without a way to recognize the original could create a duplicate. Define how the connection should preserve the correct business result when a request is repeated, then test that behaviour with the systems involved.
Also decide what happens to incomplete records, rejected updates and information received out of sequence. Which problems can be retried? Which require a person to correct the data? What should users see while the issue is unresolved? Specify where failures become visible and who is responsible for them. An integration is difficult to operate when the only sign of a problem is a customer calling.
Retail shows why the whole information journey matters
Nexo’s retail platform connects point-of-sale information from thirteen physical stores with inventory, ecommerce and a management dashboard. The work brings store information into both the online shopping experience and management reporting, connecting the data with the interfaces people use.
When planning your own connection, follow a single item through the proposed systems. For example, ask what each view should show after a sale, a return or a stock correction. Write down the expected quantity, status and timing at each step. This gives the team concrete results to check across the whole journey.
Verify the records and the experience built on them
Test with representative records and agreed expected outcomes. Check ordinary transfers, duplicates, missing values, delayed updates and recovery after a failure. Compare the relevant records in both systems. A request being accepted does not prove that the intended business state now exists.
Then check the interface used by the people relying on the information. Can they tell which period a figure covers and whether the data is current enough for their task? Can they identify an unresolved item? Agree who will maintain field mappings and review changes when either system evolves. An initial connection is one delivery milestone within an ongoing operating responsibility.
Write an integration brief before estimating the build
A concise brief should give business and engineering teams the same definition of a correct result. Unresolved questions are useful at this stage: make them visible so they can be investigated before they become assumptions in the implementation.
- What event starts the flow, and what verified outcome ends it?
- Which system owns each fact, and how is the same record identified?
- How current must the information be for each use?
- What should happen after a duplicate, conflict or failed transfer?
- Who investigates differences and maintains the connection over time?
Make the missing connection concrete.
Tell us which systems are involved, what information should move and who needs to use it.
Discuss your integration
