Skip to content

Connecting your systems, ending duplicate data entry

When the same information is maintained in two programs there are two versions — and nobody knows which one counts. We build the connection between them: with a check before the handover, a response in both directions, and a defined route for everything the target system does not accept.

Visual metaphor for connected systems: streams passing through shared connections.
Illustration: connecting systems and data flows.

Typical occasions

  • Orders from the shop are transferred into the ERP system by hand.
  • Master data is held in two systems and differs between them without anyone noticing.
  • A service provider delivers a file every day that someone opens, checks and processes.
  • A report is created afresh every week from three sources — always by the same person.
  • An existing connection has not run for weeks, and nobody has noticed.

What we take on

  • Agreeing the field mapping: which detail in one system corresponds to which in the other — and which is deliberately not transferred.
  • Connecting to existing interfaces of third-party systems, including authentication and management of the access keys.
  • Building an interface of our own where your system does not offer one.
  • File-based reconciliation where that is the more robust solution — it often is.
  • Rework for rejected cases: one place where a person can see what did not go through.
  • Monitoring with notification when a transfer fails to arrive.

The return path is half the work

An interface that works in the normal case is half finished. What makes it operable is its behaviour in the exceptional case — and that is best seen in a run:

Example transfer run

  • accepted Order 10244 Created in the target system, order number reported back.
  • rejected Order 10245 Item 7781 unknown in the target system. The case is in rework and waiting for a decision.
  • accepted Order 10246 Created in the target system, order number reported back.
  • retrying Order 10247 The target system was unreachable. Attempt 2 of 5; if the last one fails too, the case appears in rework.
Example data for illustration, not a depiction of a particular system. What matters is the right-hand part of each line: an interface does not only transfer, it also answers what happens to a rejected case.

From this follow four properties we design every connection for: recognisable error responses instead of a bare "error", repeatability without duplicating a case, traceability of every transfer, and a place for the cases that do not go through even after several attempts.

Six questions settled before building

  • Which system leads? Where data contradicts, one side has to win.
  • Which fields are mandatory, and which values are permitted?
  • How is authentication done, and who manages the access keys?
  • How often and in what volume is data transferred? Are there rate limits?
  • What happens on a rejection — retry, discard, notify someone?
  • Who notices when the connection has not run for three days?

Whoever answers these six questions beforehand has the hard part behind them. Whoever skips them answers them later in operation — under time pressure.

How current does the data really have to be?

This one question decides effort and technology. For many workflows this morning's state is exactly right; then a nightly reconciliation is the more robust and cheaper solution. Only when a case has to appear in the target system within minutes are real-time notifications worth it — and those additionally need a plan for lost messages.

We therefore do not recommend the most technically elaborate route, but the one that fits your answer to this question. Which technology is used is something we settle on the basis of the systems involved.

Common misunderstandings

Almost every system can at least export or import a file. That is enough for a nightly reconciliation — which in many cases is all that is needed.

Technically possible, practically risky: it bypasses the target system's checks, and the next update can change the structure. As a permanent solution only with the vendor's explicit approval.

An existing interface saves building one, not the agreement: field mapping, permissions, volumes, error cases and testing remain.

Then the connection has to follow. That is why every interface comes with the question of who notices a transfer that fails to arrive — and support that can react to it.

Have your systems connected

Tell us the two sides and what is to be transferred. The only required details are your email address and a few sentences about the task. Under "What is this about?" choose "Interface".

Development enquiry

For development work: a new application, an extension, or taking over existing software.

Tell us briefly about your idea or your existing application. Technical documents and a finished specification are not needed for a first enquiry.

Which task should become easier, and for whom?
This is how we will reply.
Optional.

Optional details — useful, but not required

If you came from a project or service page, this is already selected.
Only if it exists. We do not need access for an enquiry.
For example an ERP system, a shop or an internal application.
"Not yet decided" is a valid answer.
Optional.
Optional. We need a phone number if you would like us to call back.

We use the information you provide to handle your enquiry. Please do not send passwords, access keys or confidential personal or customer data.

How we process the information you provide is set out in our privacy notice.

Read on first