# Workflow automation with n8n: when a node is enough

> When n8n is the right tool for workflow automation and when the pipeline belongs in code: API orchestration, middleware sync, LLM steps, operations.

Quelle: https://kontrollfeld.de/en/articles/workflow-automatisierung-n8n/
Sprache: en
Veröffentlicht: 2026-09-17
Hinweis: KI-generiert, menschlich reviewt.

---
Two systems that have to agree on the same facts, and between them a cron job written three years ago by someone who has since left. That is the normal state of any grown system landscape. The job runs at night, never reports in, and when it fails, finance or support notice first. The question is rarely **whether** such a process should be automated — it already is. The question is in what form: as a workflow in a tool like n8n, or as a pipeline in the repository.

We run n8n self-hosted and use it where it is the more honest answer. This article describes where that line runs in our projects, how we cut workflow automation with n8n in practice — API orchestration, middleware synchronisation, data and document flows with an AI step — and what belongs in operations rather than in the design.

## Where n8n is enough — and where it isn't

n8n is a workflow tool: you chain triggers, HTTP calls, transformations and target systems into a graph. Every node is a step, and every run is inspectable with the actual data that passed through it. That inspectability is the real gain over a silent cron job — not the graphical interface.

The decision comes down to a handful of criteria:

| Criterion | n8n | Pipeline as code |
|---|---|---|
| Many systems, little logic in between | good fit | overhead |
| Business logic with state, edge cases, calculation rules | gets unwieldy | good fit |
| Automated tests, CI, code review | weak | core strength |
| Changes without a deployment, including by non-developers | good fit | deployment required |
| High throughput, large data volumes | limits are reachable | good fit |
| Individual runs must be traceable | built in | you build it |

The rule we work by: **transport, triggering and chaining go into n8n — business logic goes into code.** As soon as a workflow starts calculating prices, distinguishing tax rates or carrying state across runs, it is in the wrong tool. A graph with forty nodes and branches is no longer a workflow; it is a program without tests.

The licence belongs in that assessment too. n8n is published under the Sustainable Use License: the source is readable and self-hosting for internal business purposes is permitted, but it is not an OSI-approved open-source licence. If you plan to redistribute or resell, check the terms first.

## API orchestration: the most common case

The standard case is unspectacular. An event in system A should trigger something in system B. A webhook or a schedule starts the run, an HTTP node fetches data, a transformation maps it to the target structure, another call writes it forward.

What n8n contributes here is its handling of the reality of third-party APIs: per-node retries with wait times, a dedicated error output instead of an abort, pagination and rate limits as configuration rather than a hand-written loop. What you still have to design, no tool will do for you:

- **Idempotency.** A second run over the same data must not create duplicates. That requires a stable key in the target system — an external ID, not a timestamp.
- **A resume point.** After a failure, the run has to know where to continue. We carry a watermark for that instead of pulling everything each time.
- **What a partial success means.** 200 of 300 records written, then an abort — is that a failure or an intermediate state? The answer belongs in the design, not in the post-mortem.

## Middleware synchronisation between line-of-business systems

The more interesting case is two systems that permanently hold the same slice of reality. In our projects that is often a pretix-based ticketing system on one side and a publishing or subscription platform on the other — events, allocations and orders here; customer accounts, subscriptions and billing there. On the ticketing side we built that connection as dedicated middleware ([ticketing platform proof of concept](/en/case-studies/ticketing-plattform-poc/)); in setups like these, n8n is the layer that triggers it, watches it and connects it to the remaining systems.

Three decisions determine whether such a synchronisation holds up:

1. **Direction of truth.** Every field has exactly one leading system. "Both sides may write" is not an architecture; it is an agreement to argue later.
2. **Deltas instead of full reconciliation.** Where the source system offers webhooks, we consume events. Where it doesn't, we poll against a watermark. The nightly full run stays as a corrective — it finds what the delta path lost, which makes it a measuring instrument, not a replacement.
3. **A conflict rule before the first run.** What happens when the same record changed on both sides? The answer is rarely "the newer one wins" — more often the case belongs on a review list for humans.

This is also where the tool's limit sits. As long as n8n moves records, triggers runs and logs them, it is used correctly. Once the mapping carries business rules — price categories, discount logic, tax distinctions — we pull that part into a separate service with tests. The workflow then calls it instead of reimplementing it.

## Data and document flows with an AI step

The third pattern connects sources nobody reviews by hand: an AI news scout that watches feeds, vendor blogs and standards pages, compares new items against what it has already seen, classifies them by topic and files the relevant ones, summarised, where they will actually be read — as a ticket, a document, a message in a team channel. The same structure carries document flows: intake, extraction, classification, filing.

The decisive point is the role of the model. The language model is **one node**, not the system. What makes the flow usable is everything around it:

- **Structured output.** The model returns fields, not prose — otherwise the next node cannot work with it.
- **Mandatory sources.** Every summary carries the link to the original. An assessment without evidence is worthless.
- **A threshold and deduplication.** Anything below the relevance threshold is not passed on; anything already reported is not reported twice.
- **A human at the end.** The scout proposes; it does not publish.

The editorial pipeline behind this website follows the same pattern — there, deliberately, as code, because it has to be versioned, tested and reviewable. That is the line from the first section, applied to our own operations. If the output of such a flow should later be queryable, the workflow doesn't end in an inbox but in a knowledge store — and choosing one follows [different criteria](/en/articles/qdrant-oder-pgvector-self-hosted-rag/). And if an assistant is meant to trigger the flow itself rather than just read its output, a control layer belongs in front of it: [your own MCP server](/en/articles/mcp-server-typescript-erstellen/) with narrowly scoped tools, not an open webhook.

## Operations: self-hosted, versioned, with an error path

n8n is quick to set up and just as quickly becomes an unsupervised system with write access to your line-of-business systems. What we therefore settle from the start:

- **Postgres instead of the default SQLite**, Docker on your own infrastructure, an encryption key that is actually set. Without a secured data directory and that key, stored credentials are unusable after a restore attempt — which you discover in an emergency, not before.
- **Workflows exported into Git.** The JSON export is versionable, which is precisely why we keep workflows small and named: a diff over a forty-node graph is no longer reviewable. Credentials sit encrypted in the database and are not part of the export — that separation has to be handled at deployment time.
- **One central error workflow.** Every production flow points to it, and alerting goes out from there. A failed run that only the UI knows about is a silent cron job with a web front end.
- **Limited retention of execution data.** n8n stores the payload of every run. With personal data, the execution history is a data set with a deletion deadline of its own, not a debugging convenience.
- **Separate environments.** A workflow that writes to production is not developed in production.

## Key takeaways

- The question is not n8n **or** code, but where to cut: transport, triggering and chaining into the tool, business logic into tested code.
- Idempotency, resume points and conflict rules determine whether a synchronisation lasts — not the number of available nodes.
- In AI steps the model is one node among many; structured output, mandatory sources and human approval are what make the flow usable.
- Operations decide the outcome: your own encryption key, workflows in Git, a central error path, limited retention of run data.
- n8n is source-available but not OSI open source — check the licence before planning redistribution.

If you want to automate recurring processes and know up front which part belongs in the tool and which belongs in code, this is how we approach [process automation](/en/services/automation/).