What is workflow automation?

The word automation suggests a large change. In practice the idea is plain. A task is written down from start to finish, and software applies that description step by step. While the rule stays the same, the result stays the same too.

A flow has three parts. The trigger starts it: a schedule, a form response, a new message or a call from another system. A step does one job and hands the result on. A condition picks the route through the flow.

Automation does not make judgements. It applies a rule somebody wrote. Which route applies in which case, and which step waits for a person, is decided before the build starts. Where the rule cannot be written down, the flow cannot be built either.

Three tests decide it. The task repeats, its rule can be written down, and its input arrives in a predictable shape. When all three hold, the flow has a long life.

Typical cases are narrow. A form entry is written into the CRM. An incoming invoice is named and filed. A daily report is assembled and sent to a channel. Records move between two systems on a schedule.

Some tasks do not suit it. A flow has a short life when 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, and the flow is built afterwards.

Three names come up most often: n8n, Make and Zapier. All three build flows, and each is stronger in a different place. The tool is chosen for the job rather than by habit.

The first test is where the data has to sit. When personal data must stay on the company's own server, n8n fits. It can be self-hosted, and the data does not leave that server. Under GDPR that makes the processing record easier to keep. Make works well on a visual canvas for flows of medium complexity. Zapier is quick for simple links between common applications.

The build document answers two questions: which flow runs in which tool, and why that tool was picked. If the tool changes later, the flow is rewritten, because flows do not transfer between tools one to one.

A flow is tested by what it does on a bad day. When a step fails, the job goes to a queue, somebody is notified and the step is retried. If the retry fails as well, the flow stops and the team is told rather than left guessing.

Every run is written to a log. The log holds the name of the flow, the time it ran, the step it reached and the result. The monthly report shows the success rate, the average duration and the number of errors still waiting.

Human approval sits inside the flow as a step. Sending, paying and deleting are hard to undo, so those steps wait for a person. The next step stays idle until the approval arrives. The speed is in the flow, and the decision stays with the team.

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

The second point is access. Flows are built in the client's own account or on the client's own server. Keys and credentials are created in the client's name, so the flow keeps working if the supplier relationship ends.

The third point is maintenance. Tools release new versions and connected services change their rules, so a flow can go quiet without anyone noticing. Flows are tested on a schedule and a backup is taken before each change. ALTAI Digital hands flows over with their documentation and writes down the reason for the tool choice.