Workflow Examples: 8 Real Processes Written Out Step by Step

Most workflow examples you'll find are diagrams with boxes labeled "Step 1" and "Step 2." Useless. What you need to see is a real process written out with real steps, real decision points, and real owners.

That's what's below — eight of them, from hiring to invoicing, each written the way you'd actually document it.

Before the examples, the one piece of theory that saves time: every workflow is one of four shapes, and knowing which one you're looking at tells you how to write it down.

Most real processes combine two. A hiring pipeline is a state machine with sequential stretches inside it. An approval chain runs legal and finance in parallel, then sends the result to an executive sequentially. Microsoft's docs on sequential versus state machine workflows is a clear primer on why the distinction exists, and if you end up diagramming any of this formally, BPMN is the notation most tools standardized on.

Sequential: employee onboarding

The most common workflow in any company, and the one most often held together by somebody's memory.

1. Offer accepted → HR marks the candidate as hired in the ATS
2. HR creates the employee record and triggers the payroll setup
3. IT provisions accounts: email, SSO, and role-based tool access
4. IT ships hardware, tracked against the start date
5. Manager assigns an onboarding buddy and books a week-one 1:1
6. Manager sets 30/60/90-day goals in the shared doc
7. Day one — new hire completes compliance training and account setup
8. Day 30 — HR sends a check-in survey

The decision point that matters: step 3 depends on the role, which determines tool access. Write that mapping down once, as a table of role to tool list, instead of asking the manager each time.

Sequential: invoice processing

1. Invoice arrives (email, portal, or post)
2. Extract vendor, amount, PO number, due date
3. Match against the purchase order
4. If matched and under threshold → auto-approve
5. If unmatched or over threshold → route to the budget owner
6. Budget owner approves or rejects
7. Approved invoices enter the payment run
8. Record archived against the vendor

Where this breaks: step 2, always. Every vendor formats invoices differently, which is why this process resists rule-based automation and is one of the clearest wins for AI extraction — an unstructured PDF becomes structured fields, and steps 3 through 8 are ordinary logic. That split is the core idea behind intelligent process automation.

Conditional: support ticket triage

1. Ticket arrives
2. Classify by intent: billing, bug, how-to, feature request
3. Billing → billing queue, 4-hour SLA
4. Bug → check for duplicates → engineering queue with severity
5. How-to → suggest three help articles → close if resolved, escalate if not
6. Feature request → log to the product board, send acknowledgment
7. Any ticket unresolved after 48 hours → escalate to a team lead

The lesson here: step 2 is the entire workflow. Classification quality determines everything downstream, and it's the step most worth measuring. Everything after it is routing.

Parallel: content publishing

1. Brief approved
2. Draft written
3. Then three things at once:
   • Editor reviews for structure and accuracy
   • Designer produces images
   • SEO check for keyword coverage and internal links
4. All three complete → revisions
5. Final approval
6. Scheduled and published
7. Post-publish: distribution and performance tracking

The tradeoff: parallel is faster but harder to track. Step 4 can't start until the slowest branch finishes, and if the designer is out, the whole thing sits. Sequential is slower but you always know exactly where a piece is.

State machine: hiring pipeline

The stages are states, not steps, because candidates move between them in ways a linear diagram can't express.

States: Applied → Screening → Phone Screen → Technical Interview → Onsite → Offer → Hired / Rejected / Withdrawn

The reason it's a state machine: a candidate can go back (onsite to a second technical round), skip ahead (a referral straight to onsite), or exit from any state at all. A sequential model breaks the first time reality doesn't cooperate.

What to define explicitly: which transitions are legal, who can trigger each one, and what happens on the exit paths. Undefined transitions are where candidates get lost — the classic being a "Withdrawn" candidate nobody ever tells.

State machine: sales pipeline

States: Lead → Qualified → Discovery → Proposal → Negotiation → Closed Won / Closed Lost

Same structure, different domain, same failure. Deals slide backward, skip stages, and go dormant. The state that actually needs defining is the one nobody adds: Stalled — a deal that hasn't moved in 30 days is not still in Negotiation, and pretending it is corrupts every forecast built on the pipeline.

Hybrid: expense approval

Where most approval processes actually live.

1. Employee submits with receipt
2. Under $100 → auto-approve, sample audited monthly
3. $100–$1,000 → manager approves (sequential)
4. Over $1,000 → manager and finance approve in parallel
5. Over $10,000 → manager and finance in parallel, then a director sequentially
6. Approved → reimbursement run
7. Rejected → returned with a reason, resubmittable

This is the shape most approval workflows converge on: parallel where speed matters, sequential where accountability does. Running legal and finance simultaneously and only then routing to an executive preserves both.

Hybrid: monthly reporting

1. Period closes — the trigger
2. In parallel: pull finance data, pull product analytics, pull support metrics
3. Consolidate into the reporting template
4. Each function reviews its own section
5. If a variance exceeds 10% → require a written explanation
6. Compile the narrative summary
7. Distribute, then archive against the period

Why this one is worth automating first: it happens on a predictable schedule, the inputs are the same every time, and it consumes a senior person's day. High volume isn't required for automation to pay off when the per-run cost is that high.

Writing your own down

Four rules that make the difference between a document people use and one nobody opens:

Name the trigger. "When a candidate accepts," not "hiring." A workflow without a defined start isn't a workflow.

One owner per step. Not a team — a role. "Engineering reviews" means nobody reviews.

Write the exceptions. The 20% of cases that don't follow the happy path are where all the pain lives. A workflow that documents only the ideal case describes a process that doesn't exist.

Note where things wait. Wait time is almost always the bottleneck, not work time. A five-step process taking nine days usually has four days of queueing in it. Fixing a wait beats optimizing a step.

For turning these into something running rather than documented, workflow management software covers the tooling side, and streamlining business processes covers what to cut before you automate anything.

Getting from a documented workflow to a running one

The step people underestimate is the one after documentation. You have the process written out and it's clear — and building it still means a workflow canvas like Zapier or n8n, or a repo, or a tool you have to learn first.

Taku is an AI-native desktop workspace built for that gap: mirror a workflow someone already got working, run it on your own files, and remix it to match the process you just wrote down — rather than assembling it node by node from zero. Browse the free app library to see what's there. Taku is in Beta.

FAQ

What is a workflow example?

A specific process written as ordered steps with defined owners and decision points — not a category like "hiring" but the actual sequence: what triggers it, who does what, where it branches, and how it ends.

What are the main types of workflow?

Sequential (fixed order), parallel (simultaneous then merged), conditional (path depends on a decision), and state machine (items move between states in any valid order). Most real processes combine at least two.

What's a workflow management system example?

A tool that runs the process rather than documenting it — tracking which item is in which state, routing to the right person, enforcing rules, and escalating when something stalls. Ticketing systems, ATSs, and CRMs are all workflow management systems specialized for one process shape.

What is the simplest workflow?

Input, process, output. Something arrives, something happens to it, something comes out. Every workflow above is that pattern repeated and branched — which is why starting by naming the trigger and the finished state, then filling in the middle, works better than listing steps in order.

How detailed should a documented workflow be?

Detailed enough that someone new could follow it without asking. That usually means naming the trigger, one owner per step, explicit decision criteria with actual thresholds, and the exception paths. Timing estimates per step are optional but reveal where the queues are.

What project workflow should a small team use?

Start with a simple state machine — Backlog, In Progress, Review, Done — which is essentially a kanban board, and only add states when you keep needing to explain where something is. Most teams add stages faster than they add value; four states that everyone updates beats nine that nobody does.