Workflow automation with n8n: pragmatism beats complexity
AI-generated, human-reviewed
In grown system landscapes the central question is not whether to automate, but where the logic lives. A silent cron job that moves data between two systems at night and alerts nobody but finance when it fails is a liability. Graphical workflow tools like n8n promise visibility — but only if they are cut correctly. This article describes how we cut and operate workflow automation with n8n in real projects.
The architectural rule: transport, routing and triggering belong in n8n. Complex business logic belongs in tested code.
1. The right cut: n8n vs. code
An n8n graph with 40 nodes, nested IF conditions and hard-coded pricing rules is no longer a workflow. It is untested code in a GUI. The interface then hides exactly what it was bought for: you see boxes, but no longer which rule applies.
The n8n path: API orchestration, receiving webhooks, routing data from system A to system B, handling pagination and rate limits. This is where the tool pays off, because every run stays inspectable with the actual payload that passed through it — the decisive difference from a silent cron job.
The code path: calculations, tax rates, complex state transitions. As soon as business rules can change, we move that logic into small, testable microservices that n8n merely triggers. The gain is not elegance but regression safety: a changed discount rule belongs in a test, not in a text field.
The rule of thumb: anything you would want to test after changing it belongs in code. Anything that merely connects stays in the graph.
2. API orchestration and middleware sync
When two line-of-business systems — a ticketing system and a subscription platform, say — have to stay in sync, hard integration rules apply. What such a connection looks like as dedicated middleware is shown by our ticketing platform proof of concept; in setups like these, n8n is the layer that triggers it, watches it and connects it to the remaining systems.
- Single source of truth: every field has exactly one leading system. Bi-directional writes without a clear master inevitably produce conflicts — and the conflict does not surface on write, but weeks later in a billing run.
- Idempotency: every run must be safely repeatable. The target system has to update via an external ID instead of blindly creating records. A timestamp is not a sufficient key.
- Deltas via watermarks: instead of pulling every record each night, n8n asks only for changes since the last timestamp. Full syncs serve at most as a weekly corrective — and whatever such a run still corrects is your measure of how tight the delta path is.
- Error routing: partial successes (a batch aborting at 200 of 300) need defined state handling. A global n8n error workflow catches failures and triggers monitoring immediately. Whether an abort is a failure or an intermediate state is your decision at design time — otherwise the next run decides it by accident.
The cut from section 1 applies here too. As long as n8n moves records and logs them, it is used correctly. Once the mapping carries price categories or tax distinctions, that part moves into a service of its own.
3. AI inside the workflow
In automations like content scraping or document classification, the LLM is just one node in the chain. What makes the flow usable is everything around it:
- Structured output: prompts must enforce JSON. Prose breaks the following n8n node.
- Deduplication and relevance: filter noise out before the AI node to save token cost and latency. Anything already reported does not go through the model again.
- Human in the loop: automated workflows prepare decisions — as a draft in the CMS, as a ticket. They do not publish unreviewed.
- Evidence required: every summary carries the link to its source. An assessment without evidence is worthless in review.
If the output of such a flow should later be queryable, the workflow does not end in an inbox but in a knowledge store — and choosing one follows different criteria. 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 with narrowly scoped tools, not an open webhook.
4. Self-hosted operations and deployment
For production use, n8n’s default SQLite database is not sufficient.
- Database: Postgres is mandatory, for stability and parallel executions.
- Versioning: JSON exports of the workflows belong in Git. Credentials stay in the database under n8n’s own encryption key. Keep workflows small and named — a diff over a 40-node graph is no longer reviewable.
- Data retention: limit executions to a few days to prevent PII leakage and database bloat. With personal data, the execution history is a data set with a deletion deadline of its own, not a debugging convenience.
- Environments: keep development and production physically separate. A workflow with write access to line-of-business systems is not developed in production.
The licence belongs in that assessment: 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.
Key takeaways
- Tool choice: n8n excels at transport, triggering and chaining APIs. Once business logic enters the picture, isolated code is the better answer.
- Architecture: stable workflows require idempotency, clear ownership (single source of truth) and clean error handling.
- Using AI: models are powerful tools inside a workflow, but they require strict guardrails — structured output and a final human check.
- Infrastructure: reliable operation rests on Postgres, sound credential management and strict deletion deadlines for runtime data.
Start a project
At Kontrollfeld we operate the systems we design. If you want to automate recurring processes and are looking for an architecture that holds up beyond the first proof of concept: get in touch.