What changes in everyday work?
What the team gains
A clear source of information
We establish which system owns each value. This prevents a customer address or order status change from circulating endlessly between programs.
Predictable exchange
Data is checked and mapped to the receiving system’s format. We agree update frequency and how repeated events will be recognised.
Errors visible to the right person
An unavailable API or rejected record enters an error-handling process. Synchronisation history helps distinguish a delay from an issue that needs a decision.
A connection starts with what the data means.
The same field can mean different things in two programs. A “delivery date” might be planned, actual or promised to a customer. Before connecting systems, we agree terminology, identifiers and update rules. Without this, automation may simply spread misunderstandings faster.
We also check where information originates and who may change it. Customer, order and batch numbers must allow records to be linked unambiguously. When data is incomplete, the integration needs a rule: reject the entry, flag it for completion or pass it on with an agreed limitation. Experience with office, manufacturing and warehouse processes helps us spot differences that technical documentation alone does not reveal.
- Passing enquiries and orders to an operational system.
- Publishing statuses and documents in a customer portal.
- Feeding reports with data from different tools.
- Imports and exports between files, APIs and databases.
API, file or database? The route depends on what is actually available.
We first verify the supplier’s documentation and access arrangements. An API may require a particular plan, impose limits or expose only some of the data. Events sent by the system support quick responses, while a scheduled file import may be sufficient for a report prepared once a day.
Direct database access requires particular care and agreement with the system owner. We favour supported methods of exchange. We do not promise integration with any program before checking its interfaces, access conditions and test environment.
Synchronisation should recover safely after an interruption.
A network connection may fail after data has been saved but before confirmation arrives. Retrying the operation should not create another order. We design event identification, duplicate checks and a way to establish which information reached the receiving system.
We agree retry rules, limits and processing order. If a response format changes or access expires, there needs to be a clear message and someone responsible for the issue. Being able to compare both systems after a longer outage also matters, rather than relying solely on individual notifications.
Start with one direction and one kind of data.
Exchanging everything in both directions is often an unnecessarily broad starting point. The first stage might send an approved order to delivery and return its status. This tests identifiers, permissions and error handling before documents, corrections and further systems are added.
- Give us the names of the programs and their versions or plans.
- Identify the data to transfer and the direction of flow.
- Define the acceptable update delay.
- Identify the person who administers each system.
From the first conversation to launch
Access verification
We check interfaces, supplier constraints and sample data. We establish the system responsible for each piece of synchronised information.
Mapping and trial
We build the first flow in an agreed environment. We test duplicates, missing values, interruptions and rejections.
Launch and supervision
We enable data exchange, event history and error handling. We define how changes made by external suppliers will be addressed.
Questions worth asking
Will data synchronise in real time?
That depends on the systems’ capabilities and the process requirements. Some integrations respond to events; others retrieve data on a schedule. We agree acceptable delays and behaviour when a source is unavailable.
Can the integration work in both directions?
Yes, if the interfaces support it and we agree how changes are resolved. We need to identify data ownership and decide what happens when two people change the same information in different systems.
What happens if a supplier changes its API?
The integration may need an update. Maintenance scope should therefore cover error monitoring, connection documentation and responsibility for adapting to supplier changes.
Do we need to exchange all our data?
Usually not. It is better to transfer the information needed for a specific task. A smaller, clearly defined scope makes permission checks, error analysis and future development easier.