Data quality at the source
Duplicate customers, item numbers that do not match, addresses without a house number. An integration multiplies those problems instead of solving them. Cleaning up always comes before connecting.
Application integrations: making systems work together without creating new problems
Building an integration takes an afternoon. Building one that is still correct three years from now is something else.
The problem is rarely that systems cannot talk
Almost every modern package has an API these days. Whether two systems can technically communicate is therefore hardly ever the problem. Yet organisations everywhere have the same complaints: data that differs between two places, orders someone retypes, a monthly export that does not add up, and a customer name spelt three different ways in three systems.
The cause lies not in the technology but in the agreements around it. Which system is leading for which data? What happens if a message does not arrive? Who notices? And who updates the integration when one of the two sides changes?
Four ways to integrate
There is no best method. There is a best method for your situation, and that depends on what you connect, how often, and how bad it is if something goes wrong.
| Method | When to choose it | Watch out for |
|---|---|---|
| Standard connector | A common combination, standard fields, no special logic | You are tied to what the connector supports; custom fields are often left out |
| Integration platform (iPaaS) | Several systems, higher volumes, a need for logging and recovery | Subscription costs; needs someone to manage it |
| Custom API integration | Specific logic, non-standard fields, no usable standard solution | Most control, most maintenance; documentation is crucial |
| RPA | The system has no usable API or import route | Works at screen level and breaks when the interface changes |
In practice you combine them. A standard connector for the main flow, custom work for the two fields it does not cover, and an RPA bot for that one old portal without an API behind it.
The six questions to answer before you build
This is the part most integration projects skip, and it explains why they still cause problems later on.
Integrations we build a lot: around Zoho
Below is a selection of the integrations we regularly deliver. If your combination is not on the list, that is rarely an obstacle: with custom API integrations we connect almost any system, including platforms you developed yourself.
-
Exact Online and Zoho CRM
The most requested combination. Customer details, invoices and payments flow between your financial administration and your CRM, so your salespeople see outstanding items without logging in to finance, and your bookkeeping does not have to retype customer data. Ownership really matters here: address details usually belong in the CRM, tax details in Exact.
-
WooCommerce and Zoho CRM
Your WordPress web shop as a sales channel, with orders, customer details and interactions landing in your CRM automatically. That turns a web shop customer into a recognisable profile instead of a row in an order overview: the basis for targeted marketing and follow-up.
-
Lightspeed and Zoho CRM
Through a custom API integration, customer and order data goes straight into your CRM. Especially valuable for organisations that also do active account management alongside their web shop and want the complete customer picture in one place.
-
Zoho CRM and Picqer
The logistics side. By connecting your CRM to Picqer you streamline the order process from purchase to shipment: orders are processed faster, customer communication is more transparent and stock levels stay up to date. Pay attention to how often stock is synchronised here: overnight updates are guaranteed to lead to sales you cannot deliver for fast-moving items.
-
Clickker and Zoho CRM
Your financial administration and your customer system as one connected whole, so your decisions rest on complete information instead of two half pictures.
-
UBO identification in Zoho CRM
An application we developed ourselves that lets you identify a customer's ultimate beneficial owner directly from Zoho CRM, as required by the Dutch anti-money laundering act (Wwft). This is an example of an integration that goes beyond moving data: a compliance process that happens in your existing working environment instead of in a separate system with its own login.
Integrations around Creatio
-
Exact Globe and Creatio
Customer information, sales data and invoices between your financial system and your BPM platform, so your processes and your administration see the same reality.
-
WordPress and Creatio
A custom API integration between your website or web shop and Creatio, with the online customer experience at the front and all the data landing automatically in your process platform at the back.
-
Creatio and Picqer
The same logistics streamlining as with Zoho, but with Creatio as the orchestration layer: orders processed quickly, transparent communication and stock levels that are right.
-
Clickker and Creatio
Financial administration and process platform in one environment, so customer, sales and financial data come together.
And if your combination is not listed
Then we build it. That is not a marketing line but our everyday work: most of the integrations we make do not yet exist as a standard product. Industry-specific packages, government portals, supplier environments, machines and in-house developed systems almost always fall into that category.
Our systems now talk to each other. The double data entry has gone, and so have the errors that came with it.
Where integrations break in practice
An update on one side. One of the two suppliers releases a new version, a field is renamed or an API version expires. Without monitoring, you only find out when the phone rings.
The integration does too much. If there is business logic in your integration (discount rules, approvals, calculations), it is in the wrong place. It belongs in one of the two systems or in a process platform. An integration should translate and transport, not decide.
Nobody looks at the logs
Many integrations log neatly, but nobody looks at the logs. An error message that reaches nobody does not exist in practice.
There is no documentation
The person who built it has left, and there is nothing written down. Every change then becomes an investigation.
Support: the part nobody sells
Building an integration is the easy part. Keeping it running for five years is the real work. In concrete terms that means: monitoring that reports when something does not come through, a log that someone actually checks, an agreement on who looks into it when something breaks, and documentation that lets another team carry on too.
We deliver integrations that can be handed over. You should be able to move away from us: an integration that only we understand is not a solution but a dependency.
How we approach an integration project
Do you not yet have a clear picture of your processes? Then a standalone process mapping workshop is often a good starting point, with no obligation to build anything afterwards.
-
We start with the process, not the systems
What needs to happen, for whom, and how often? Sometimes it turns out half the requested synchronisation is not needed at all.
-
We record ownership per data item
In a matrix both sides understand.
-
We choose the method
Connector, platform, custom build or RPA, based on volume, complexity and the effort of managing it.
-
We build in error handling, logging and retries
Not as an afterthought.
-
We test with real data
Including the odd cases that always turn out to exist.
-
We deliver with documentation and monitoring
And agree on how it will be supported.
An integration is not a goal, but an agreement that gets carried out
Connecting systems is not about technology. It is about recording who is responsible for what, and then having software carry that out instead of people who hopefully remember it.
That is why we always start with the question of which system is leading for which data, and why we only hand over an integration once it is clear who will manage it. Zoho, Creatio, your accounting system, your web shop and your warehouse system can work together perfectly well, provided someone has made the agreements.
Frequently asked questions about application integrations
-
That varies widely. A standard connector between two common packages is mainly a matter of configuration and takes days. A custom API integration with non-standard fields, business rules and high volumes takes weeks. The biggest cost driver is rarely the technology but the complexity of the agreements: how many fields, how many directions, how many exceptions. Always ask about the support costs too, because they keep running.
-
A simple, one-way integration with a limited number of fields is usually up and running within a few weeks, including testing. More complex projects with several systems, two-way traffic and data migration take several months. In practice, analysing and cleaning up data takes more time than building.
-
Then there are still three routes. Many packages offer an import or export route via files, which is less elegant but robust. Some suppliers offer database access. And if neither exists, an RPA bot can carry out the actions the way an employee would. That last option is more vulnerable to interface changes, but it works, and with older industry packages and supplier portals it is often the only option.
-
Not one system for everything, but per data item. Customer name and contact details usually belong in your CRM, tax details and invoices in your accounting system, stock and item data in your ERP or WMS. Record that per field before you build. This is the most important decision in the whole project and at the same time the one most often skipped.
-
That depends entirely on how it was built. A good integration detects errors, retries when there is a temporary outage, logs everything and sends a notification to a designated person. A bad integration lets messages quietly disappear. With every quote, ask explicitly how error handling and monitoring are arranged: that is the difference between an integration you trust and one you have to check regularly.
-
Yes. In practice we regularly come across integrations that were once built by someone who has since left, without documentation and without monitoring. We first map out what actually happens, repair or rebuild where needed, and make sure it can be handed over from then on.
-
With two systems and a simple flow, a direct integration is perfectly fine. As soon as you connect more than three systems, or when volumes rise and you want to be able to recover from errors, an integration platform is usually the wiser choice. You then get logging, buffering and retries as standard instead of building them for each integration. The trade-off is a subscription and someone to manage it.
-
An integration transports and translates data between systems. Process automation determines what should happen with that data: which steps, which approvals, which exceptions. The two must stay separate. As soon as business logic creeps into your integration, it becomes unmanageable: put that logic in one of the two systems or in a process platform.
Is there still an Excel sheet sitting between two of your systems?
Tell us about it.