Workflow integration is the practice of connecting applications so data moves between them automatically - and the difference between an integration layer that helps and one that becomes the most feared part of the system is a handful of decisions made early.
Every organisation past a certain size has an integration layer, whether or not anyone designed one. It is either a deliberate set of connections with owners and error handling, or a sediment of scripts, spreadsheets, and one workflow somebody built before they left. The second kind is more common.
Table of contents
- The four ways systems get connected
- Push beats pull, almost always
- The three properties that separate robust from fragile
- Where the swamp comes from
- A design that stays maintainable
- How this fits the rest of the stack
- FAQ
The four ways systems get connected
- Point-to-point. System A calls system B directly. Simplest possible thing, fine for two or three connections, and quadratic in complexity as systems are added. Ten systems fully connected is forty-five relationships nobody is tracking.
- Hub and spoke. Everything talks to a central integration layer, which handles routing and transformation. Fewer relationships, one place to look, and one thing whose outage is everyone’s outage.
- Event bus. Systems publish events without knowing who consumes them; consumers subscribe. Excellent decoupling, and harder to reason about because no single place describes what happens when an order is created.
- Batch and file transfer. Nightly exports and imports. Deeply unfashionable, entirely appropriate for reconciliation and reporting, and far more robust than its reputation suggests.
Most real environments contain all four, which is fine. Trouble comes from not knowing which pattern a given connection uses, or from using an event bus for something that needed a synchronous answer.
Push beats pull, almost always
The most consequential technical choice in any integration is how the receiving side learns something happened.
Polling asks repeatedly whether anything changed. It works with any system that has an API, needs no cooperation from the source, and is easy to build. It is also slow by design, consumes quota on every empty check, and pushes you into rate limits as soon as you shorten the interval to make it feel responsive.
Webhooks have the source notify you when something happens. Immediate, cheap when nothing is happening, and dependent on the source supporting them and your endpoint being reachable and reliable.
Where webhooks are available, use them. Polling every thirty seconds is not real-time - it is a nervous refresh button wearing a fake moustache, and it costs you on every iteration where nothing happened. Keep polling as a fallback for systems that offer nothing better, and widen the interval as far as the business tolerates.
The three properties that separate robust from fragile
- Idempotency. Processing the same message twice must produce the same result as processing it once. Webhooks get retried, queues deliver more than once, and networks fail after the work was done but before the acknowledgement. Give every operation a key, record what you have processed, and ignore repeats. Without this you will eventually create duplicate orders, and you will find out from a customer.
- Retries with backoff. Downstream systems go down. Retry with increasing delays, cap the attempts, and put permanent failures somewhere a human will see them - a dead-letter queue, a table, an alert. What must not happen is silent discard.
- Observable failure. For every integration, someone must be able to answer what ran, what it did, what failed, and whether anyone was told. An integration that fails quietly is worse than one that does not exist, because the organisation is making decisions on data it believes is current.
These three are unglamorous and they are the entire difference between an integration layer you trust and one you route around.
Where the swamp comes from
Integration layers rot in a recognisable way, and the causes are organisational more than technical.
No owner. An integration is built by whoever needed it, often outside engineering, and then that person changes role. Two years later it breaks and nobody knows what it connects to. This is the dominant failure mode, and the fix is a register: what connects to what, who owns it, and what happens if it stops.
No versioning. The workflow lives only in a tool’s interface, with no history, no review, and no way to see what changed last Tuesday. Export definitions into version control even if the platform is the only thing that can run them.
Business logic hidden in transformations. A pricing rule expressed as a field mapping in an integration tool is invisible to everyone reading the application code. When the numbers are wrong, nobody looks there. Keep logic in the application and mapping in the integration.
Credentials with more access than needed. Integrations tend to accumulate broad API keys because narrow ones were fiddly. Scope them at creation and rotate them when people leave.
A design that stays maintainable
Prefer events over polling wherever the source allows. Put a queue between anything that can fail and anything that must not block. Make every handler idempotent from the first version rather than after the first duplicate. Keep transformation in the integration layer and decisions in the application. Give every integration a named owner and a documented failure path.
And be honest about the boundary. Visual workflow tools are excellent for connecting systems and poor at expressing logic - once a canvas is fifteen nodes deep with nested branches, it wants to be a small service in a repository with a test and a review history. The graduation is normal and the hybrid is often best: the trigger and routing stay visual, the complicated part becomes an endpoint the workflow calls.
How this fits the rest of the stack
The queue, the worker, and the endpoints that hold the complicated parts of an integration all need somewhere reliable to run. The RunxBuild hosting calculator prices the service, the database that holds processed-message keys and execution history, and the bandwidth as separate items. RunxBuild runs n8n as a managed tool with custom domains, environment variables, autoscaling, and logs, alongside services in Node, Python, Go and Docker and managed MySQL and Postgres, so the visual half and the coded half can live in the same account.
Useful related references:
- Workflow Builders: What They Replace and Where They Stop
- n8n Workflow JSON: The Structure, and How to Edit It by Hand
- Coding Agents in 2026: The Real Cost, the Real Runtime, and the Real Workflow
- Builds on RunxBuild
FAQ
What is workflow integration?
Connecting applications so data moves between them automatically instead of a person copying it. It covers point-to-point calls, a central hub, an event bus, and scheduled batch transfers - most organisations use all four, and problems come from not knowing which pattern a given connection uses.
Should integrations use webhooks or polling?
Webhooks wherever the source system supports them. Polling works with anything and requires no cooperation, but it is slow by design, consumes quota on every empty check, and hits rate limits as soon as you shorten the interval. Keep polling as a fallback, not a default.
What is idempotency and why does it matter?
Processing the same message twice producing the same result as processing it once. Webhooks get retried, queues deliver more than once, and networks fail after work completes but before acknowledgement. Without idempotency you will eventually create duplicate records and hear about it from a customer.
Why do integration layers become unmaintainable?
Usually four reasons: no named owner once the person who built it moves on, no version history because the workflow lives only in a tool’s interface, business logic hidden inside field transformations where nobody looks for it, and credentials scoped far more broadly than needed.
When should an integration become real code?
When the visual workflow exceeds roughly fifteen nodes, when branches nest deeply enough that the diagram no longer fits a screen, or when you cannot answer what changed last week. A hybrid works well: keep the trigger and routing visual, move the complicated logic into an endpoint.