System integration
Data moves between systems without retyping
The same piece of information often gets entered several times: in the CRM, in a spreadsheet, in the accounting system. Every retyping costs time and creates an opening for a mistake. An integration moves data in an agreed direction, keeps the fields consistent and flags cases where two systems hold different versions.
We start with one pair of systems and the flow that takes the most time. Further directions come later.
- 01
One entry, several systems
You enter the data once. The integration moves it to the other tools in the agreed direction and format.
- 02
Resilience to errors
A failed transfer returns to the queue and is retried. Cases that stay unresolved go to a named person.
- 03
A view of the flow
You can see what went through, what is waiting and what was stopped, along with the reason it stopped.
What we connect most often
We start with the flow that takes the most time today, or the one that most often ends in an error in the data.
-
CRM
An enquiry from a form into the CRM
A message from the website, the inbox or a chat becomes a CRM record with a full set of fields and an assigned owner.
-
Accounting
An order in the accounting system
An approved order creates a sales document without anyone re-entering the line items or the customer details.
-
Warehouse
Stock levels held in several places
A change in stock updates the shop and the sales system at an agreed rhythm, with no manual export.
-
Email
Attachments from the inbox into a system
An invoice or an order sent as an attachment reaches the right record, with its fields read out and the original file kept.
-
Spreadsheets
A spreadsheet inside the process
The spreadsheet stays where the team finds it convenient, but data arrives in it and comes back out of it automatically.
-
Industry systems
A program with no open interface
Where a system offers no API, we move the data by export, an exchange file or access to the database.
How an integration works
The connection works on every data change, including the times when one of the systems is temporarily unavailable.
- 01
Field mapping
We agree which fields correspond to each other, how dictionaries are translated, and what happens to data the other side will not accept.
- 02
Direction of synchronisation
For each field we name the leading system. Where the exchange runs both ways, we agree which change takes precedence.
- 03
Queues and retries
Events wait in a queue. When a system does not respond, the integration retries rather than losing the data.
- 04
Monitoring and alerts
Every operation is logged. A recurring error raises an alert to the person responsible for the process.
Scope of implementation
The scope depends on the number of systems, whether their interfaces are available, the number of fields, and the direction the data has to travel.
On our side
- a review of your systems and the interfaces available
- mapping of the fields and the translation rules
- building the flow with a queue and retries
- testing on a copy of the data and on edge cases
- monitoring, alerts and documentation of the flow
What we need from you
- access to the systems being connected
- someone who knows the data on each side
- a list of mandatory fields and the dictionaries in use
- approval to test on a copy of the data before the switch
From one flow to a permanent link
Stage 1
System review
We check which interfaces your systems offer and what limits come with them.
Stage 2
Data mapping
We agree the matching fields, the direction of the flow and the way gaps and duplicates are handled.
Stage 3
Build and testing
We run the flow on a copy of the data and check how it behaves on errors and on breaks in access.
Stage 4
Switching over
We turn the integration on against live data, enable the alerts and hand over the view of the flow.
Common questions
Answers on systems without an API, on two-way exchange, on outages and on the load placed on your tools.
We look at the other routes for exchanging data: file export, database access, system notifications or an import function. If none of them is available, we say so before the work starts and propose a different scope.
Contact
Discuss your data flow
In the first conversation you name the systems, the data your team retypes by hand today, and the point where errors most often arise. Afterwards we set out the scope needed for a fuller assessment.
- 01
Systems
You list the tools your team moves data between by hand today.
- 02
Data and direction
We establish which information should travel across and which system leads on it.
- 03
Further assessment
We set out which access rights and limits have to be checked before the scope can be defined.