What Is a Workflow? Definition, Examples and How to Build One

A workflow is a repeatable sequence of tasks that moves a piece of work from a starting trigger to a finished outcome, with each task done by a specific person or system in a defined order. When a supplier invoice arrives, it is logged by accounts payable, matched against the purchase order, approved by the budget holder, scheduled for payment and filed: that is a workflow. It has a trigger (the invoice arriving), steps, hand-offs between roles, a decision point (does it match the PO?) and an outcome (a paid, filed invoice).

Every team runs dozens of workflows whether or not anyone has written them down. The difference between a team that runs smoothly and one that constantly firefights is rarely that one has better people. It is that one has made its workflows explicit, so that work moves through the same steps every time, hand-offs do not get dropped, and the lead can see where everything is without asking.

This guide is for operations, IT, HR, finance and team leads at companies of 10 to 500 people who want to understand what a workflow actually is, how it differs from a process or a project, what a well-built one contains, and how to map, document and eventually run their own. It includes eight real workflow examples across departments, a seven-step method for documenting a workflow, and a comparison of the diagram types you will encounter.

What Is a Workflow?

The word gets used loosely, so it is worth pinning down. A workflow has four defining characteristics. It is repeatable: it runs the same way for every instance, whether that is every invoice, every new hire or every support ticket. It is sequenced: the steps happen in a defined order, even if some can run in parallel. It involves hand-offs: work passes from one person, role or system to another, and those transitions are where things go wrong. And it has a defined outcome: you know when a run is finished and what "finished" produced.

A workflow is not the same as a list of things to do. A to-do list is personal, unordered and never finished. A workflow is shared, ordered and complete when the outcome is reached. It is also not a description of everything a team does; it is a description of one thing the team does repeatedly, from its trigger to its end.

The distinction between the design and the run matters more than it first appears. The employee onboarding workflow is a design that exists once. Onboarding Priya, who starts on the 14th, is a run of it. Most of the trouble teams have with workflows comes from confusing the two: they document the design carefully and then have no idea how many runs are in flight, which are late, or whether the last one was completed at all.

Workflow vs Process vs Project vs Checklist vs Task

Five words get used interchangeably in most offices and they describe different things. Getting them straight is not pedantry; it decides which tool you reach for and how you measure success. The table below separates them by scope, repeatability and what "done" means.

The relationship between process and workflow is the one that causes most confusion. A process is the wider thing with an owner, a purpose and measures: employee onboarding as a whole. A workflow is a concrete, executable path through it: the IT provisioning workflow, the HR paperwork workflow, the manager's first-week workflow. One process usually contains several workflows. When people say they are "managing their processes", they typically mean they are running their workflows deliberately, which is what business process management formalises.

A checklist is simply the most practical form a workflow takes when people, rather than software, are doing most of the steps. A well-designed checklist and a well-designed workflow are the same object described from different angles: one emphasises the steps, the other emphasises the flow between them.

The Three Types of Workflow

Workflow theory recognises three structural types. Most real workflows are a mix, but knowing which type dominates tells you how to draw it, how to document it and what your tooling needs to support.

Sequential workflows

Steps happen one after another, each depending on the previous one. Step three cannot start until step two is done. Employee offboarding is largely sequential: you disable the account, then remove it from groups, then recover the device, then close the record, and doing them out of order creates security gaps. Sequential workflows are the easiest to document and run, and a numbered checklist with enforced ordering handles them completely.

State-machine workflows

The work moves between defined states rather than along a fixed line, and can go backwards. A support ticket is New, then Assigned, then Awaiting customer, then back to In progress, then Resolved, then perhaps Reopened. A contract in review can bounce between legal and the counterparty several times. State-machine workflows need a clear definition of each state, what is allowed to move work between states, and a way of seeing how long work has sat in each one. Kanban boards are state machines drawn as columns.

Rules-driven workflows

The path through the workflow depends on conditions evaluated as it runs. A purchase request under £500 goes straight to the budget holder; between £500 and £5,000 it also needs a department head; above £5,000 it goes to finance and the managing director. An IT change classified as "standard" skips the change advisory board; one classified as "major" does not. Rules-driven workflows are the most powerful and the easiest to get wrong, because every branch has to be specified and tested. In checklist terms, they are what conditional logic exists to handle: steps that appear, disappear or change assignee based on earlier answers.

In practice, most business workflows are sequential at the top level with rules-driven branches at two or three decision points, and one or two state-machine loops where work waits on an external party. Recognising that pattern makes them much easier to map.

The Anatomy of a Workflow

Every workflow, from a two-step approval to a forty-step client onboarding, is built from the same six parts. When you map a workflow, you are identifying these six things. When a workflow fails, it is almost always because one of them was left implicit.

1. Trigger

The event that starts a run. It can be an action (a customer signs a contract), a schedule (the first Monday of the month) or a condition (stock drops below a threshold). Workflows with unclear triggers do not start reliably: if "someone should kick off onboarding when a hire is confirmed" does not say who or on what signal, some hires will not be onboarded until they turn up. Naming the trigger precisely is the single highest-value thing you can do when documenting a workflow.

2. Tasks

The individual pieces of work. Each should be small enough to be done in one sitting by one person, described with a verb, and have an observable result. "Set up laptop" is too vague; "Image laptop with standard build, join to domain, install the department's software bundle, record the asset tag" is a task someone can complete and someone else can verify.

3. Roles

Who does each task. Roles rather than names, so the workflow survives staff changes: "hiring manager", "IT engineer on rota", "budget holder". At run time each role resolves to a person. A workflow where every step is assigned to "the team" will have steps that nobody does.

4. Hand-offs

The points where work passes from one role to another. Hand-offs are where delays, dropped work and misunderstandings concentrate, because they depend on one person knowing that another has finished. A good workflow makes every hand-off explicit: what is passed, to whom, and how they find out. Much of the value of workflow software is that it performs the hand-off automatically rather than relying on an email.

5. Decision points

Places where the path depends on a condition: approved or rejected, matches the PO or does not, standard change or major change. Each decision point needs a defined question, a defined set of answers and a defined path for each answer. "Use judgement" is not a decision point; it is a gap in the workflow that will be filled differently by each person who reaches it.

6. Outcome

The state of the world when the run is complete, stated so that anyone can confirm it. "New hire has logged in on day one with working laptop, email, and access to the four core systems" is an outcome. "Onboarding done" is not. The outcome is also what you measure against: if runs reach the outcome late, or reach a different outcome, the workflow needs changing.

A Short History of Workflows

The idea that work should be broken into defined steps, sequenced and assigned is older than the word. A brief history explains why workflows look the way they do and where the diagram conventions came from.

Frederick Winslow Taylor's scientific management, set out in his 1911 book, argued that every job had a best method that could be discovered by observation and timing, then taught and enforced. Henry Gantt, who worked with Taylor, wanted a way to see that method against time: which tasks, in which order, taking how long, and where the whole thing stood today. The Gantt chart, developed in the 1910s, was the first widely used tool for making a sequence of work visible, and it is still the default view of a project plan.

Henry Ford applied the same thinking to manufacturing at scale. The moving assembly line introduced at Highland Park in 1913 broke the building of a Model T into small, sequenced tasks performed by fixed roles as the work moved past them. Chassis assembly time fell from over twelve hours to around ninety minutes. The line was a workflow in physical form: a trigger (the next chassis arrives), tasks, roles, hand-offs and an outcome, with the sequence enforced by the conveyor rather than by a supervisor.

Office work took the same route more slowly. Through the twentieth century, paper forms, in-trays and routing slips carried work between desks; the "workflow" was the route the form took. In the 1980s and 1990s, document imaging and early workflow management systems put that routing into software, and the Workflow Management Coalition, founded in 1993, began standardising how such systems described and exchanged workflows. In the same period, Michael Hammer and James Champy's Reengineering the Corporation argued that companies should redesign their workflows around outcomes rather than departments, which is where the swimlane view of a workflow crossing several teams became standard.

The 2000s brought the Business Process Model and Notation standard and enterprise BPM suites that could model a workflow in BPMN and execute it directly. The 2010s and 2020s brought the opposite end of the market: cloud tools that let a team lead build a workflow as a template, assign steps to people, add conditional logic and see every run on a dashboard, with no analyst involved. That is the setting most readers of this guide are in.

8 Real Workflow Examples by Department

Abstract definitions only go so far. Here are eight workflows that exist in almost every company of 20 or more people, described the way you would document them: trigger, steps and outcome. Notice how similar their shapes are despite the different departments; that similarity is why one approach to running workflows can cover a whole company.

1. New-hire IT provisioning (IT)

Trigger: HR confirms a start date for an accepted offer.
Steps: IT lead assigns an engineer → engineer orders or allocates hardware (due ten working days before start) → creates directory account, email and licences → images the device with the standard build → grants access to core systems based on the role → ships or hands over the device → new hire confirms first login on day one → engineer records asset tags and closes the run.
Outcome: the new hire is working on day one with everything they need, and the asset register is up to date. See the IT onboarding checklist guide for the full step list.

2. IT change management (IT)

Trigger: an engineer submits a change request.
Steps: requester classifies the change (standard, normal, major) → for standard changes, a peer approves; for normal and major, the change manager assesses risk and impact → major changes go to the change advisory board → approved changes are scheduled into a maintenance window → the implementer applies the change with a rollback plan ready → the implementer verifies and records the result → the change manager closes the record.
Outcome: a change applied to production with an approval, a rollback plan and a record, or a change rejected with a reason.

3. Employee offboarding (HR and IT)

Trigger: a resignation is accepted or a termination is confirmed, with a last day.
Steps: HR opens the run and notifies IT, payroll and the manager → manager plans knowledge transfer → HR schedules the exit interview → on the last day, IT disables the account, removes group memberships and revokes SaaS access → IT recovers the device and confirms data is preserved → payroll processes final pay → HR closes the record.
Outcome: the leaver has no access to any system, all equipment is returned, final pay is correct and the record is complete.

4. Month-end close (Finance)

Trigger: the last working day of the month, on a recurring schedule.
Steps: AP closes the purchase ledger → AR closes the sales ledger → the accountant posts accruals and prepayments → bank accounts are reconciled → intercompany balances are agreed → the finance manager reviews the trial balance → management accounts are produced → the finance director signs off.
Outcome: management accounts issued by working day six, with every reconciliation evidenced. Our month-end close checklist guide covers each step.

5. Invoice approval (Finance)

Trigger: a supplier invoice arrives.
Steps: AP clerk logs the invoice and matches it to a PO → if it matches and is under threshold, the budget holder approves → if over threshold, the finance manager also approves → mismatches are returned to the supplier with a query → approved invoices are scheduled for the next payment run → the record is filed.
Outcome: the invoice is paid on time with a documented approval, or returned with a documented reason.

6. Content production and approval (Marketing)

Trigger: a piece is scheduled in the content calendar.
Steps: the content lead briefs the writer → the writer drafts → an editor reviews for accuracy and style → the designer produces visuals → if the piece makes product or legal claims, the relevant reviewer signs off → the content lead publishes → the social media manager schedules distribution → performance is reviewed after 30 days.
Outcome: a published, reviewed piece with distribution scheduled and a performance review booked.

7. Client onboarding (Client services)

Trigger: a contract is signed.
Steps: the account manager sends the welcome pack and schedules a kick-off (due within three working days) → the client completes an intake form → the technical team configures the account and integrations → the account manager runs the kick-off call and agrees success measures → training sessions are delivered → a 30-day review is held → the account is handed from onboarding to ongoing account management.
Outcome: a client who is live, trained, has agreed success measures and knows who their ongoing contact is.

8. Support ticket resolution (IT or client services)

Trigger: a ticket is raised by email, portal or phone.
Steps: first-line triages, sets priority and either resolves or assigns → the assignee investigates and either resolves or escalates to second line → if waiting on the customer, the ticket pauses and a chase is scheduled → the resolver records the fix and asks the customer to confirm → after confirmation or a set period without reply, the ticket closes → tickets breaching the response or resolution target are flagged to the desk lead.
Outcome: the customer's issue is resolved and confirmed within the service level, and the fix is recorded for the knowledge base.

Look at the shapes again. Four of the eight are almost purely sequential (provisioning, offboarding, month-end, client onboarding). Two are rules-driven at one or two points (change management, invoice approval). Two are state machines with loops (content approval, support tickets). All eight have a clear trigger and outcome, which is what makes them workflows rather than "things that happen".

Why Documenting Workflows Matters

Most teams run their workflows from memory and habit, and most of the time it works. The cases where it does not are expensive enough that documenting the important ones pays for itself quickly.

Hand-offs stop being dropped. An undocumented workflow depends on each person knowing that it is now their turn. When the person before them forgets to say so, is on holiday or leaves the company, the work stops and nobody notices until the outcome is late. A documented workflow with explicit hand-offs, and ideally software performing them, removes that dependency.

New people become productive in days. A new IT engineer who inherits a documented provisioning workflow can run it in their first week with a senior checking the completed runs. One who inherits "ask Dave" will take a month and still miss steps Dave never mentioned. Documentation is how a team stops depending on the memory of its longest-serving member.

Problems become visible before they become complaints. Once a workflow is written down, it is possible to say where a run is, which step is late and who is holding it. The lead can act on the 20th of the month rather than on the 1st of the next one.

You can improve what you can see. A workflow that exists only in people's heads cannot be analysed. Documented, it can be measured (cycle time, late steps, rework loops), compared between runs and changed deliberately. This is the foundation of process mapping and improvement work.

Evidence exists. For anything touched by a regulator, an auditor or a customer's security questionnaire, a documented workflow with a record of each run is the difference between "we have a policy" and "here are the last twelve completed runs with names and dates".

Documentation also has a cost, and it is worth being honest about it: a documented workflow has to be kept current, or it becomes a misleading artefact that describes how things used to work. That is why the how-to below ends with review rather than with publishing.

How to Map and Document a Workflow in 7 Steps

This is the method for taking a workflow that currently lives in people's heads and turning it into something that can be reviewed, run and improved. It takes an afternoon for a typical 15-to-25-step workflow, most of which is spent talking to the people who do the work.

Workflow Diagrams: Flowchart, Swimlane, BPMN and Value Stream

Step six above says "draw it". There are four diagram types you will meet, and choosing the right one depends on who the diagram is for and what question it needs to answer. Most team-level workflows need nothing more than the first two.

Flowchart

Boxes for tasks, diamonds for decisions, arrows for sequence. Universally understood, quick to draw, and the right choice for a workflow that is mostly performed by one or two roles. Its weakness is that it does not show who does what, so a flowchart of a workflow crossing five teams hides the hand-offs, which are usually the part you most need to see. Our guide to process flowcharts covers the symbols and conventions.

Swimlane (cross-functional) diagram

A flowchart divided into horizontal or vertical lanes, one per role or team, with each task placed in the lane of whoever performs it. Every time an arrow crosses a lane boundary, that is a hand-off. This makes swimlanes the best diagram for spotting where work waits, bounces or falls between teams, and the right default for any workflow involving three or more roles. Onboarding, change management and client onboarding all belong in swimlanes.

BPMN (Business Process Model and Notation)

A formal standard with a defined vocabulary of events, activities, gateways and pools that can express timing, messages, exceptions and parallel paths precisely, and which some engines can execute directly. It is the right choice when the diagram has to be unambiguous to a developer or an analyst, when the workflow has complex exception handling, or when you are documenting for a regulated environment. For a team lead mapping onboarding, full BPMN is more notation than the problem needs, although its swimlane conventions are worth borrowing. See business process modelling for a fuller treatment of BPMN and when it earns its keep.

Value stream map

A Lean tool that draws a workflow as a series of steps annotated with the time each step takes, the time work waits between steps and the information flows that trigger each step. Its question is not "who does what" but "where does the time go", and it exposes the difference between a workflow's touch time (typically hours) and its lead time (typically weeks). Use it when the aim is to shorten cycle time rather than to document the sequence.

Common Workflow Mistakes

The same handful of errors account for most workflows that are documented but do not work. All of them are fixable at the mapping stage if you know to look.

From Diagram to Execution: What Workflow Software Adds

A documented workflow tells people what should happen. It does not make it happen, tell anyone whose turn it is, or record whether it was done. That gap is what workflow software closes, and it is worth being specific about what "closing it" means, because the market ranges from simple checklist apps to enterprise orchestration platforms and most teams need a defined middle.

• The workflow is a template, and each instance is a run. The design exists once; every run is created from it, so all runs follow the current version and a change to the template reaches every future run.
• Steps are assigned to roles that resolve to people. The "hiring manager" step goes to Priya's actual hiring manager; the "engineer on rota" step goes to whoever is on rota that week. Nobody is chased by email.
• Due dates are relative to the trigger. "Ten working days before the start date" rather than a date typed in by hand, so the same template works for every run and overdue steps are calculated automatically.
• Hand-offs happen automatically. When one step completes, the next assignee is notified. The person before them does not have to remember to say so.
• Decision points are conditional logic. Steps appear, disappear or change assignee based on earlier answers, so one template handles a standard change and a major change without showing every path to every requester.
• Calendar-driven workflows recur on a schedule. Month-end close, monthly patching and quarterly access reviews are created and assigned automatically on their cycle. Recurring checklists are how most teams first experience this.
• Evidence is captured at the step. Forms and required fields mean the asset tag, the approval and the reconciliation are recorded where they are produced, and a step cannot be completed without them.
• Every run is visible on one dashboard. Which runs are active, where each one is, which steps are overdue and who is holding them, without asking anyone.
• Every run leaves an audit trail. Who did each step, when, and with what result, exportable for an auditor, a customer or a post-incident review.
• Other systems can start and receive runs. Integrations, webhooks or an API let the HR system start the onboarding run and let the completed run update the asset register, which is the first step towards workflow automation.

The order of that list is deliberate. Teams get most of the benefit from the first five items, which are about making the documented workflow the running workflow. Recurrence, evidence and dashboards come next. Integration and automation come last, once the workflow has run the same way for long enough that automating it will not bake in a mistake.

Free Workflow Templates to Start With

Three of the eight examples above are available as ready-built templates. Each opens as a working workflow with steps, roles and due dates already defined, so you can adapt it to your team rather than start from a blank page.

Employee Onboarding Checklist

Runs a new hire from accepted offer to 90-day review, with HR, IT and manager steps assigned and due relative to the start date.

IT Incident Management Process Checklist

Takes an incident from detection through triage, escalation, resolution and post-incident review, with every step and decision recorded.

Invoice Approval Workflow Checklist

Routes a supplier invoice from receipt through PO matching, threshold-based approval and payment scheduling to a filed record.

How CheckFlow Fits

CheckFlow is workflow software for the human-centric workflows in this guide: the ones where most steps are a person doing a task and handing it on. It is built around the template-and-run model described above, at the scale of a team rather than an enterprise, and a team lead can have a first workflow running in an afternoon without an analyst or a developer.

You build each workflow in the template designer from the steps, roles and decision points you mapped. Each step is assigned to a named person or to a role that resolves per run, so the same onboarding template sends the laptop build to whichever engineer is on the rota and the first-week check-in to the actual hiring manager. Due dates are dynamic: relative to the run's start, to a date field such as the new hire's first day, or to the completion of an earlier step. Conditional logic shows, hides or reassigns steps based on answers given earlier in the run, which is how one change-management template handles standard, normal and major changes.

Workflows that run on a calendar, such as month-end close or monthly patching, are set to recur daily, weekly, monthly or on a custom schedule, with each run created and assigned automatically. The real-time dashboard shows every active run, which step it is on, what is overdue and who is holding it. Every completed step is written to an audit trail with the person, the time and any evidence captured in form fields. Zapier and a REST API let other systems start runs and receive their results, so the HR system can trigger onboarding and a completed run can update the asset register; the automations page covers what can be wired up.

Pricing starts from $10 per user per month, with a 14-day free trial and no credit card required. If your workflows are mostly people doing tasks in a defined order, and you want the documented version to be the one that runs, it is built for that.