What is n8n?

n8n builds a workflow step by step. At the front sits a trigger: a time of day, a new form response, an incoming email or a call from another system. When the trigger fires, the flow starts.

After the trigger come the nodes. Each node does one job: write a row to a sheet, pull data from an API, parse incoming text or send a message. Nodes connect to each other and data moves along the line.

Conditions and branches live inside the flow as well. A record that meets a test takes one path, and everything else takes another. A step can wait for human approval, and the next node stays idle until that approval arrives.

n8n runs in two ways. The first is the vendor's cloud version: you open an account and your flows run there. The second is self-hosting, where the software is installed on a server the business owns or rents.

With self-hosting the data stays on that server. Customer details, documents and records that pass through a flow do not leave it. Under GDPR that makes two questions easier to answer: where personal data sits and how long it is kept.

In return, maintenance moves to the business. The server needs updates, backups and access control. A small team that does not want that work can have the setup run by a supplier, with the arrangement written into the contract.

All three build flows, but they sit in different places. Zapier is quick for simple links between common applications, and it comes with many ready templates. Make works well on a visual canvas for flows of medium complexity.

n8n differs on two points: it can be self-hosted, and it lets you write code. A node can hold JavaScript or Python, so a flow still finishes where a ready node falls short. Because the source is open, what a flow does can be read.

Pricing works differently too. Cloud services usually charge by runs or operations, while a self-hosted setup costs what the server costs. The tool is chosen for the job, and the reason is written down.

n8n suits repeated work whose rules can be written down. Typical cases: moving a form entry into the CRM, filing an incoming invoice, or sending a daily report to a channel.

The second fit is moving data between systems. Applications with an API connect directly. Where there is no API, an export file or a database read serves as the bridge. The direction is agreed first: one way or both ways.

Some work does not suit automation. A flow has a short life if the decision changes with every case. The same holds when the rule cannot be written down, or when the process changes every few months. In those cases the process is simplified first.

The first point is documentation. Every flow is written up with its trigger, its steps and what it does on failure. Without that, nobody can say why a step is there once the person who built it has left.

The second point is the error queue. When a step fails, the job goes to a queue, someone is notified and it is retried. If the retry fails as well, the flow stops and the team is told. Every run is written to a log, so the success rate and pending errors show up in the monthly report.

The third point is updates. n8n releases often and nodes change, so a backup is taken before an update and flows are tested afterwards. ALTAI Digital builds flows in the client's own account or on the client's server. Each flow is handed over with documentation, and the reason for the tool choice is written down.