Automate the process that is repetitive, has a clear rule and happens many times a day. n8n is very good at orchestration between systems, meaning receive, transform, decide and deliver. It is a poor choice for heavy computation or for the core business logic of your product.
Visual automation tools have left the realm of improvisation. It is now common to find workflows with hundreds of steps processing hundreds of messages a day without intervention, provided they were built with the same care you would give any other software.
How to pick the first process
Three criteria, all required:
- Repetitive and frequent. Something that happens dozens of times a day. A monthly task does not pay for the automation.
- A clear rule. If the person doing it today can explain it in five minutes, it can be automated. If the answer is “it depends, we work it out as we go”, the process needs defining first.
- Tolerable failure. Start with something where a mistake costs an apology, not money. Confidence is built.
The usual candidates look the same everywhere: logging a request that arrived by message, confirming an appointment the day before, chasing a missing document, routing a ticket by type, generating a recurring report, alerting when a metric leaves its range.
Where n8n is the right tool
It shines as the glue between systems. Pick up an event in one place, reshape the payload, decide where it goes and deliver it somewhere else. The ready-made connectors for common tools save weeks, and the visual flow lets the people who run the process see it without depending on whoever wrote it.
It also works very well for orchestrating calls to language models, whether to classify a message, pull information out of a text or draft a reply. The AI step becomes one node in the middle of a flow with deterministic rules around it, which is exactly where it belongs.
Where it is the wrong tool
- Core business logic. The rules that define your product belong in code, with tests and version control.
- Heavy data processing. A hundred thousand rows inside a visual flow is misery and memory. That is a job for the database or a script.
- Synchronous responses. If a user is waiting on screen, you want an API, not a chain of nodes.
- Scattered secrets. Credentials typed into a node, unmanaged, are a security problem waiting to happen. Use the tool’s credential store.
A workflow in production needs the same care as software
This is where most automation projects fail. An unmonitored workflow is worse than a manual process: when a human forgets, someone notices. When a silent workflow breaks, nobody notices for three weeks.
The minimum:
- Failure alerts. An error on any run posts to a channel somebody actually reads. Not optional.
- Retry with backoff. External services fall over constantly, and trying again in five minutes fixes most of it.
- Duplicate protection. The same notification will arrive twice. If the flow does not check, the customer gets two messages.
- A separate test environment. Editing the workflow that is currently serving customers is how accidents happen.
- Version control. Export the workflows to a repository. Without it, the only record of what changed is the memory of whoever changed it.
A concrete case
A construction company with a vehicle fleet needed to control refuelling. The driver photographed the pump, noted the odometer, sent it to a group chat, and someone consolidated it into a spreadsheet at the end of the day. Information went missing constantly and nothing could be verified.
The workflow took over receiving the message, asking for whatever was missing, checking the odometer made sense against the previous entry, storing the photo and the values and writing everything to a database. The same design later covered candidate screening, offboarding checklists and administrative requests, until it reached six modular workflows on a shared foundation.
The bigger win was not the time saved. It was finally having trustworthy data on consumption per vehicle, something the spreadsheet never delivered.
Start small, and measure first
Time the manual process for a week before automating it. Without that number you will not know whether the automation was worth it, and you will struggle to justify the next one.
Need this solved at your company?
A twenty minute call is usually enough to tell whether it makes sense, and you talk straight to the engineer who builds it.