Glossary
Workflow
A workflow is a sequence of steps that runs in a set order, each step's output feeding the next, and it exists whether people or software are the ones doing the work.
In plain terms
It is the order things happen in. An invoice arrives, somebody checks it, somebody approves it, somebody pays it, somebody files it. That is a workflow, and it existed long before anybody thought about automating any of it. The word is often used as though it meant software, which it does not: it means the sequence, and software is one way of running one.
Why it matters
When an automation project disappoints, the first place to look is whether it automated the documented process rather than the real one. Mapping what actually happens, including the spreadsheet somebody keeps on the side and the step that exists only because of a system nobody uses any more, produces value before a single thing is connected. It also gives you the words for what you actually want, which turns out far more often to be removing three steps than adding a model to one of them.
How it works
Three things define one: what starts it, the steps in order, and the handoffs between them. The handoffs matter more than people expect, because that is where time is lost and where information quietly fails to travel. A step needing a piece of context the previous one never passed on is a defect you will find in a great many processes, automated or not.
The documented sequence and the real one nearly always differ. People invent workarounds for the parts that do not work, and those workarounds become the process without anybody recording them. Ask somebody to describe the procedure and you get the official version; follow one real case from start to finish and you get the one your organisation actually runs.
The exceptions are the substance rather than the noise. The path where everything is in order is straightforward and rarely where the cost is. What consumes your people is the invoice in the wrong currency, the request from a customer on an unusual contract, the approval needed from somebody on leave. Those cases are also the ones nobody has written down.
Waiting dominates the elapsed time, and this surprises people every time it is measured. A process that takes a fortnight usually contains a couple of hours of work and thirteen days of queueing, which is why making each step faster changes almost nothing. What changes the total is removing a handoff or removing a wait.
There are three ways to improve one, in descending order of value and ascending order of how often they are tried: remove steps, reorder or merge them so a wait disappears, and have software do a step somebody was doing by hand. Reaching for the third without doing the first is how organisations end up with a fast, reliable version of a process they should not have had.
One invoice, as it actually moves
An invoice, as an illustration: twelve minutes of work across five days
Seen in the wild
Draw a sequence in an automation builder before connecting anything to anything, which forces you to name every step and every handoff out loud.
ZapierOpen a flow somebody else built and read only the branches, because the exceptions are where the real process is recorded.
n8nBuild the branching version of a sequence and count how many branches handle the exception rather than the rule.
Make
Common misconceptions
People assume
A workflow is a piece of software.
In fact
It is a sequence, and it exists whether or not anything runs it automatically. Every organisation has hundreds of them and has automated a handful. Confusing the two leads to conversations about which platform to buy before anybody has agreed what the sequence should be.
People assume
The documented process is the process.
In fact
It is the version somebody wrote down once, usually before three systems changed. The real one includes the workarounds, the side spreadsheet and the step everybody skips. Following one genuine case end to end tells you more in an afternoon than any amount of reading procedure documents.
People assume
Automating it will make it faster.
In fact
It will make it reliable and consistent, which is worth having, and it usually will not touch the elapsed time, because the elapsed time is mostly queueing rather than working. Removing a wait or a handoff changes the total. Making a two-minute step take two seconds does not.
Telling them apart
Workflow vs Automation
Workflow
The sequence itself. Exists in every organisation, mostly unautomated, mostly undocumented, and describable on a whiteboard.
Software running that sequence without a person, on a trigger, following steps decided in advance.
You can draw one and never automate a step of it. Automation is something you do to a workflow, not another word for one.
Workflow vs Workflow orchestration
Workflow
What should happen, in what order. A description of the work.
The machinery that makes multi-step work run dependably: ordering, retries, state, and picking up after something fails at three in the morning.
The first is a business question and the second is an engineering one. Anything running at volume needs both, and they are usually decided by different people.
Questions
- How do I map ours?
- Follow one real case from the moment it arrives to the moment it is finished, and write down every step, every handoff and every wait, including the ones people apologise for. Do it twice with two different cases. What you get will differ from the written procedure, and the difference is usually where the improvement is.
- Should we fix it or automate it first?
- Fix it. Automating a sequence with three unnecessary steps gives you those steps for ever, executed reliably, and makes them harder to remove because something now depends on them. The order that works is remove, then simplify, then automate whatever survives.
- Where does the time actually go?
- Into queues, nearly always. Measure the elapsed time of one real case and then add up the minutes anybody spent working on it, and the gap is usually startling. That gap is the thing worth attacking, and it responds to removing handoffs rather than to speeding up steps.
- How do I tell whether one is worth automating?
- Frequency, stability and how obvious a failure would be. Frequent, unchanging and loudly wrong when it breaks is the ideal candidate. Rare, changing every quarter, or failing silently is the profile that produces an automation nobody maintains and eventually nobody trusts.
Key takeaways
- A workflow is the sequence, not the software, and exists whether or not anything automates it.
- The real one nearly always differs from the documented one, and following a live case is how you find it.
- The exceptions carry the cost, and they are the part nobody wrote down.
- Elapsed time is mostly queueing, so faster steps rarely change the total.
- Remove steps first, reorder second, automate third, in that order.
Last checked July 2026