n8n is not a strategy. It is a very good hammer, and here is exactly when to reach for it.

Visual workflow tools — n8n, Make, Zapier, Power Automate — have made a genuinely large amount of automation possible for people who cannot write a service. That is a real gain and we are not sniffy about it. Most of the back-office automation we ship runs in n8n on purpose.

But there is a predictable point at which a workflow tool stops being an accelerant and becomes a liability, and almost everyone hits it the same way.

The failure mode, precisely

It is not performance. It is not scale. It is silent, unversioned change to business logic that nobody can review.

Someone edits a node on a Thursday. Nobody knows. There is no diff, no pull request, no test, and often no record of who changed what. Three weeks later invoices are being coded to the wrong account and the investigation begins with "when did this start?" — a question the tool frequently cannot answer.

The severity of that scales directly with how much judgement lives in the workflow. Moving a file from a mailbox to a folder: fine, edit away. Deciding whether a document's extracted values are confident enough to write into a system of record: not fine. That is a compliance-relevant decision and it needs to live in code, in a repo, under review, with tests.

The line we draw

In practice that means the workflow orchestrates and calls out to small, versioned services for every step that involves a decision. The extraction service, the confidence gate and the writer are code with tests. The mailbox trigger, the routing and the filing are nodes. Your operations lead can change the second category safely, and cannot accidentally change the first.

Four things to do the day you adopt it

1. Get the workflows into version control. n8n workflows export as JSON. Commit them, on a schedule, automatically. You now have a diff and a history, which is 80% of the problem solved for an afternoon's work.

2. Separate environments. A production instance that nobody edits directly and a development one where changes are made and promoted. The most common thing we find is a single instance where every change is a production change.

3. Make failures loud. Default behaviour on error is often "the execution stops and sits in a list nobody reads". Every workflow needs an explicit error path that pages a human. Silent failure is worse than loud failure, because loud failure gets fixed.

4. Make it idempotent. The same email will arrive twice. The webhook will retry. Key every write on a business identity — not on execution order — so a replay reconciles instead of duplicating. This is the single most common defect we find in inherited workflows.

When to reach for Temporal or plain code instead

Move up the stack when any of these are true: the process runs for days and must survive restarts; correctness under partial failure genuinely matters; the logic needs real tests; the same pattern is repeated across many workflows and wants to be a function; or the volume makes per-execution pricing absurd.

Do not move up the stack because the visual tool feels unserious. That is aesthetics, and aesthetics is a bad reason to hand a maintenance burden to a team that cannot carry it.