What is a workflow? The fixed sequence behind every repeatable task.

The short answer. A workflow is a sequence, not a system.

What is a workflow? It is the fixed path a piece of work follows from the moment something triggers it, a new lead arriving, an invoice landing in an inbox, a support ticket being raised, through to the outcome that closes it out. Each step in that path has an owner, an input it needs before it can start, and an output it hands to the next step. IBM's technology research team defines it in almost identical terms: a repeatable series of tasks that need to happen in a particular sequence to complete a piece of work.

It is worth being precise about what a workflow is not. It is not the same as a business process, which is the broader thing a company delivers, onboarding a new client, for instance, and which can contain several linked workflows plus the people, systems and data around them. A workflow is one specific sequence inside that larger process. And a workflow is not automation either; automation is what happens when software takes over steps a person previously carried out by hand. A workflow can be entirely manual, run on paper or muscle memory, and still be a real workflow, just an undocumented and fragile one.

Why it matters. What happens when nobody has actually mapped it.

Every business already runs on workflows, whether anyone has written them down or not. The problem is not the absence of a workflow; it is the absence of a documented, agreed one. When three different people on a team each carry a slightly different version of "how we onboard a client" in their heads, the business is not running one workflow, it is running three, and the gaps between those three versions are exactly where handoffs get dropped and clients chase for updates that should have happened automatically.

The commercial case for getting this right has strengthened as automation has become cheaper and more accessible. Camunda's 2026 State of Agentic Orchestration report found that organisations investing in process automation had, on average, automated 48% of their processes and believed they could push that figure to 64%, with 95% of those that had invested reporting increased business growth as a result. None of that is possible without a workflow that has first been mapped clearly enough for software, or a person following a checklist, to execute consistently every time.

The same report found that 71% of organisations are already using AI agents somewhere in their operations, though only 11% of those use cases have reached production. The gap between those two numbers is instructive: most of the failure sits not in the technology but in workflows that were never precise enough for an agent, or a new hire, to follow without a person filling in the missing judgement calls by hand.

How it works. The parts every workflow actually has.

Strip any workflow back and the same handful of elements show up every time:

• A trigger. The event that starts it: a form submission, a signed contract, a date on a calendar, an email landing in a shared inbox.
• A sequence of tasks. The ordered steps between trigger and outcome, each with a clear owner and a clear "done" condition.
• Decision points. Places where the path branches depending on a condition, an order over a certain value needing a second approval, for example.
• Handoffs. The moments work passes from one person or system to another, which is where most delays and dropped balls actually happen.
• An outcome. The state that marks the workflow as complete: an invoice paid, a client onboarded, a ticket closed.

Mapping those five elements out, even roughly on a whiteboard before it goes anywhere near software, is usually enough to expose where a workflow is genuinely broken rather than just slow.

A practical example. Turning a vague habit into a real workflow.

Take a small agency's client onboarding. Before it is mapped, it looks like "someone sends a welcome email and sets up a folder", which is not a workflow, it is a vague habit that varies by whoever is doing it that week. Mapped properly, the trigger is a signed contract landing in the CRM. Step one is an automated welcome email. Step two is account manager assignment, owned by the operations lead, due within one business day. Step three is a kickoff call booked directly into the client's calendar. Step four is project folder and access provisioning, owned by IT, triggered by the kickoff call being confirmed. The outcome is a completed onboarding checklist visible to the whole team.

Written out that way, the workflow is something a new hire could run correctly on their first week, something software could partially automate without a person needing to remember each step, and something a manager could actually audit when a client complains their onboarding felt slow. None of that is possible while the process only exists as a shared assumption about how things "usually" get done.