Workflow automation: start with the job nobody wants to do twice

A request lands in an inbox. Someone copies it into a register, asks another person to check it, then chases an answer. Everyone involved may be doing their part perfectly well. There is still a lot of moving information around.

Workflow automation can take on some of that movement. The useful question is which steps have clear rules and which need somebody who understands the job. Start with one request and follow it through. You will learn more about what to build than you would from comparing a dozen platforms.

Decide which part can follow a rule

Most workflows can be sketched as trigger, checks, actions and an outcome. A new form arrives. The data is checked. The right person gets it. A record is created. Somebody is notified only when they need to make a decision.

Look for repeated work with clear inputs and outputs. Good first projects are usually smaller than the process everyone calls 'the big transformation'.

A workflow can move information quickly and still be wrong. Keep people in the loop for sensitive decisions, ambiguous requests, public communications and anything where an incorrect action is expensive or hard to undo.

Ask: what do we do repeatedly that would be easier if the boring movement happened by itself? That question produces better projects than asking which automation platform to buy.

• Trigger: something happens.
• Checks: rules decide what should happen next.
• Actions: software moves, creates or updates something.
• Human review: a person steps in where judgement matters.
• Outcome: the process reaches a useful state and is logged.
• Copying information between systems.
• Sending the same reminder after a predictable event.
• Creating standard folders, documents or tasks.
• Routing enquiries or requests to the right owner.
• Publishing one approved record to several channels.

Walk through an equipment request

This is a worked example, not a reported AutomateNI result. A community workshop receives a request to borrow a projector. The useful first version creates a task for the equipment coordinator and attaches the original request. It does not approve the loan.

Give each request a stable ID. Check that an item, return date and contact route exist before creating the task. If the same request arrives twice, find the existing task instead of creating another. Put the approval decision after these checks.

A rejection is a valid outcome. Record it against the request and stop. An unanswered approval should stay visibly waiting, with a named role responsible for following up; it should never become an approval just because time passed.

Write the failure branch at the same time

If the task system is unavailable, keep enough information to recover and show the coordinator that the request needs attention. A backup record alone is not evidence that a notification arrived. For an n8n implementation, an error workflow can handle failed executions; its behaviour still needs testing.

Run the workflow with a normal request, a repeated ID, a missing date and a disconnected destination. Compare the outcome with the expected result for each test. Only then try a small live batch with the coordinator watching.

Decide what to keep

Measure the manual task before the trial and the checking effort during it. Include time spent fixing records and maintaining the workflow. If recovery takes longer than the copying it replaced, simplify the experiment.

Use the Workflow Planner to record the owner, stop condition and tests. Its saved file is a handover note, not an instruction to turn every step on.

Trace one item before connecting everything

Take one made-up request and follow it on paper. For the projector example, write down request EQ-014, the item being borrowed, the requested dates and the coordinator who checks availability. Now draw the places that information passes through. You may discover that three people maintain slightly different copies of the same register. Agree which record is authoritative before connecting them.

The workflow needs a definition of each state. Received means the input exists. Ready for review means required checks passed. Approved means an authorised person agreed to this particular request. Completed means the promised action happened. Those words prevent a green tick from covering several different things, and they make a useful screen for somebody who has never opened the workflow editor.

Use ordinary language for the rules. A return date before the collection date should produce a correction request. A missing availability record should go to the coordinator. The system should never invent a date to keep moving. Work through these branches with the person doing the job, because they will know exceptions that the form designer missed.

Choose an implementation you can understand

A short script is a reasonable fit when the input is a local file and the output is another file. A visual workflow can suit a hand-off between services that already expose the information you need. Existing software may already offer a rule or approval feature. Check that first; connecting another platform brings another account and another place to investigate failures.

Node-RED passes messages between nodes and provides a Debug node for inspecting their contents. That is a useful learning exercise: inject a made-up request, inspect it, change one field and inspect it again. Keep the final step as a debug output until the values look right. The point is to understand what crosses each connection before allowing a connection to create something elsewhere.

Microsoft's approval walkthrough shows an explicit approval action followed by a condition on the response. Whatever software you choose, keep that decision visible. Sending an approval email is not approval, and a person saying yes to version one should not silently authorise a changed version two.

Sources: Node-RED: working with messages, Microsoft: create and test an approval workflow.

An AI step needs its own reason to exist

A date comparison, folder name or duplicate check can follow an explicit rule. There is little value in asking a language model to guess the answer to a question you can calculate directly. Start with that predictable core. It makes a smaller first build and gives you something you can explain to the person who will maintain it.

If requests arrive as messy free text, a model might help prepare a suggested description or category. Treat that as a separate experiment. Keep the original request available and let someone check the suggestion before it affects the loan. A workflow with no AI can be complete; adding a model does not make the surrounding checks optional.

The same design transfers to physical projects. A sensor reading can become an input, a threshold can become a check and a small display can become an output. You still need to distinguish a fresh reading from an old one. That is why a lesson from a silly desk gadget can turn out to be useful when you return to an office process.

Make the trial easy to inspect

Prepare a tiny set of fictitious records rather than copying the whole live register. Include one valid request, the same request twice, two different requests from the same person and one request with a missing item. The first should reach review once. The duplicate should point to the existing record. The second genuine request must remain separate. The incomplete one should explain what is missing.

Then interrupt a run after the task is created but before its notification is recorded. This is a more revealing test than simply unplugging everything at the start. On recovery, can you find the task that already exists? Write down the answer and the recovery procedure. Use n8n's error-workflow documentation if that is your chosen platform, but test the complete path through your own connected services.

Keep the first release small enough to remove. One coordinator, one equipment type and one agreed trial period give you a chance to learn without rebuilding the organisation. At the end, ask the coordinator what became easier and what became harder. A shorter queue, fewer copied fields or a clearer handover can each be useful outcomes. Record which one you actually observed.

Sources: n8n: handling workflow errors.

Sources and further reading

• n8n: handling workflow errors. Primary documentation for failure workflows, rather than evidence of a particular time saving.
• Microsoft: create and test an approval workflow. Primary documentation showing an explicit approval step and its outcomes.
• Node-RED: working with messages. Message objects, inspecting their contents and changing properties in a flow.

Continue with

• Task automation: start with the small job you keep putting off
• Document workflow automation: six jobs to stop doing by hand