Most SMEs eventually connect a handful of their systems to each other: the CRM that should update accounting when a deal closes, the webshop that should create an order in the warehouse system, the HR tool that should provision a new starter's accounts elsewhere. Our guide to automating business processes covers the no-code side of that — Zapier, Make, n8n, and the processes worth automating first. This guide picks up where that one stops: what happens once a connection needs more than a no-code platform's standard connectors, and how to build it so it keeps working a year later instead of becoming the one integration nobody dares touch.
Where no-code tools stop being enough
A no-code platform works well as long as both systems offer a standard connector and the logic stays simple: when this happens here, do that there. You hit the edge of that fairly predictably:
- One of the systems has no official connector. An older ERP, a specialised industry application, or anything built in-house exposes data through its own API, if it exposes anything at all, and someone has to write code against that API directly.
- The logic needs to span multiple steps with real error handling. A single trigger-action pair is easy to reason about. A chain of five steps where step three can fail independently of the other four, and needs its own retry and alerting, usually outgrows a visual workflow builder.
- The data crossing the connection is sensitive, and you need specific control over where it's logged, how long it's retained in transit, and who can see it — control a generic connector wasn't built to give you.
- You're connecting the same two systems in more than one direction, and keeping several separate no-code workflows in sync with each other becomes its own maintenance burden.
None of this means the no-code platform was the wrong starting point. It means the project has grown past what that layer is for, and the next step is a connection built directly against the systems' own APIs.
Three ways to structure a connection
Point-to-point. System A talks directly to system B. Simple to build and simple to understand for one connection. The problem shows up as you add more systems: five systems connected point-to-point can mean up to ten separate connections, each with its own authentication, error handling and quirks to maintain. What looked simple at two systems becomes a tangle at five.
A central integration layer. Instead of every system talking to every other system, each one connects once to a shared layer that routes data between them. Adding a sixth system means building one new connection to the hub, not five new connections to everything already in place. This costs more to set up for just two systems, which is exactly why point-to-point is the right call when two is all you'll ever have, and the hub is the right call once you can already see a third or fourth system coming.
Event-driven versus scheduled. A webhook pushes data the moment something changes — an order is placed, a status flips — so the other system reacts in close to real time and no API calls are spent checking for nothing. Polling asks "anything new?" on a fixed schedule instead, which is simpler to build and reason about, but means a built-in lag between the event and the reaction, and calls spent checking even when nothing changed. Use a webhook when the receiving system supports one and near-real-time matters; polling is a reasonable, simpler default when it doesn't.
What actually breaks an integration in production
The build itself is rarely where an integration project fails. It fails later, quietly, in ways that look a lot like the quiet failures our database migration guide describes for data moves — the same discipline applies here, because an integration is really a migration that never stops running:
- An external API changes without warning. A vendor renames a field, deprecates an endpoint, or tightens a rate limit, and an integration built against the old behaviour starts failing or, worse, silently returning incomplete data.
- Authentication expires. An API key gets rotated on the other side, or an OAuth token's refresh wasn't configured correctly, and the connection stops working between visible symptoms rather than at a moment anyone's watching.
- Rate limits bite during busy periods. An integration that works fine in testing can start failing exactly when volume is highest — the Black Friday order spike, the month-end invoice run — because nobody tested it under real load.
- A retried step creates a duplicate. If a step fails partway through and gets retried without being built to handle that safely, the same order or invoice can get created twice. Designing each step so running it again has the same end result as running it once, rather than assuming it will only ever run once, is what prevents this.
- The same field means different things in each system. A "status" field that means something slightly different in the CRM than in the accounting package is the same data-mapping problem our database migration guide covers, just happening continuously instead of once during a cutover.
The question most integration projects skip: who's responsible for the data
When an integration sends personal data — customer records, order details, employee information — to a third-party system, that third party is processing personal data on your business's behalf. Under the GDPR, that makes your business the controller and the third-party system the processor, and the relationship between you has to be governed by a written contract, not just a technical connection. The European Data Protection Board's own guidance for small businesses is specific about what that contract needs to cover: the processor may only process the data on your instructions, must keep it confidential and secure, must help you respond to data-subject requests and notify you of a breach, and — relevant specifically to integrations — cannot bring in a sub-processor of its own without your prior written authorisation and a genuine chance for you to object. The EDPB is equally direct about liability: as the controller, you remain responsible for your chosen processor's compliance, not only your own.
In practice, this means that before you connect a new system into the chain, it's worth checking two things: whether a data processing agreement already covers that specific connection, and whether the new system brings in a sub-processor of its own (a cloud platform behind an integration tool, for instance) that nobody authorised in writing. An integration that was approved as a technical project can quietly become a compliance gap if a new downstream system gets added to the chain later without anyone revisiting that agreement.
Security habits that slip under deadline pressure
Store API keys and secrets in a secrets manager or your platform's built-in credential store, not hardcoded in a script or dropped in a shared spreadsheet "just for now." Scope each credential to the minimum access the integration actually needs, rather than reusing one broadly privileged key across every connection because it's already there. Revoke and rotate credentials the day someone who had access to them leaves, the same discipline our cybersecurity and identity team applies to any other account. And log what moved, and when — not for its own sake, but because the alternative to a log, when a customer says an order never arrived, is a guessing match between two systems that both insist they did their part.
Build it so the next person isn't guessing
Give every integration a named owner, the same rule our process-automation guide gives for no-code workflows: one with nobody responsible for it quietly breaks the moment a connected system changes something. Monitor it actively — an alert the moment a connection fails, not a customer complaint three days later as the first sign anything was wrong. And document the mapping itself: which field in system A lands in which field of system B, and why a particular choice was made where the two systems don't quite agree on what a field means. That document is the thing someone reverse-engineers under pressure, at the worst possible time, when it doesn't already exist.
Rolling it out without betting everything on day one
Start with one connection, proven against real data, before it becomes the only path those records travel. Run it alongside the existing manual process for a period rather than switching over immediately, so a mapping error surfaces as a discrepancy you can check rather than a customer-facing problem. Only once the first connection has run cleanly through a normal business cycle — including the busy days, not just the quiet ones — does it make sense to add the next one.
Common mistakes
Building a mesh instead of a hub once a third or fourth system is already on the horizon. Point-to-point is fine for two systems and increasingly expensive for every one after that.
No plan for what happens when the other side is down. An integration that assumes the other system is always reachable fails in exactly the way that matters most: during someone else's outage, not yours.
Treating a successful test as a finished integration. A connection that works against clean test data behaves differently against a real system's edge cases, retries and odd historical records.
Adding a new downstream system without checking who now sees the data. Each new hop a piece of personal data takes is a question worth asking before it's wired in, not after.
FAQ
What does it cost to connect two business systems? It depends heavily on whether a no-code connector already exists for both systems, how much custom logic the connection needs, and how sensitive the data is. A connection between two mainstream SaaS tools with an existing no-code connector is a different project from one involving a legacy system with no modern API at all — get a quote based on your specific systems rather than a general figure.
Can we just use Zapier or Make instead of building something custom? For most standard connections between mainstream tools, yes — see our guide to automating business processes for how to pick the right no-code platform. Custom integration becomes worth its cost once a system has no official connector, the logic needs multi-step error handling, or the data involved has specific security or contractual requirements a generic connector doesn't give you.
Does every integration that touches personal data need a new contract? Not if an existing data processing agreement with that third party already covers the connection. It's worth checking specifically when a new system enters the chain, or when an integration tool itself relies on another provider behind the scenes that nobody has separately authorised.
How do we know if an integration is actually reliable, not just working today? Ask what happens when the other system is unreachable, when a step is retried, and when the data volume triples for a day. An integration that has only ever been tested against the happy path hasn't really been tested.
Getting it built so it stays built
The integrations that cause the fewest problems a year later are the ones designed with the failure cases in mind from the start, not the ones built fastest. Our Web & Software Development team builds the custom connections a no-code platform can't reach, with the error handling, monitoring and documentation that keep them running quietly. Where the right answer is a workflow on n8n, Make or Zapier instead, our AI & Automation team builds that side of it too, as part of the same conversation about what your systems actually need to talk to each other.