Workflow Diagram Examples: Six Diagrams for Ops Workflows, Including the Paths Most Examples Leave Out

A workflow diagram shows the steps of a piece of work in order, the decisions that send it down different paths, and where it starts and ends. Most examples online show the happy path: request comes in, someone approves, done. That is enough to explain a process to a new hire. It is not enough to build an automation from, because automations spend most of their complexity on the paths a happy-path diagram leaves out: rejections, timeouts, retries and failures.

Each example below is an illustrative workflow written for this guide, not a real company’s process. Each one shows a different diagram pattern, and each includes at least one of those missing paths. They are drawn as text so they can be copied into a document or a ticket and redrawn in any diagram tool.

The symbols you need

Workflow diagrams use a small set of flowchart shapes. The text versions below draw each shape with the notation in the right-hand column.

Shape	Meaning	How it appears in the text examples
Rounded rectangle/oval	Start or end of the workflow	(Start) / (End)
Rectangle	A task: something a person or system does	[Schedule publish]
Diamond	A decision with two or more outgoing paths	<Both approved?>
Parallelogram	Input or output, such as a form or a file	/Access request form/
Hourglass or clock	A wait: for a time, a date or an external event	{Wait for fields updated}
Arrow	The order of steps; labelled arrows leave decisions	--yes-->

If a diagram will be read by developers or loaded into a process engine, use BPMN instead. The BPMN 2.0.2 specification from the Object Management Group defines separate symbols for events, tasks, gateways and message flows, which removes ambiguity a plain flowchart leaves in. For internal design work, the shapes above are enough.

1. Content approval: a decision loop

Pattern: a loop back to an earlier step. Most approval diagrams show approve and reject; real approvals mostly produce “changes requested”, which sends work back.

(Start: draft marked ready)
  -> [Assign reviewer by content type]
  -> [Reviewer reviews]
  -> <Decision?>
       --approved--> [Schedule publish] -> (End: published)
       --changes requested--> [Writer revises] -> back to [Reviewer reviews]
       --rejected--> [Notify writer with reason] -> (End: archived)
  Loop guard: on the third "changes requested", route to the editor instead of the reviewer

The loop guard is the part worth copying. Without a limit, a piece can circle between writer and reviewer indefinitely, and the diagram never shows it. Decide what happens on the Nth loop, and draw it.

2. Software access request: parallel approvals

Pattern: a split into parallel branches and a join. Two approvals that don’t depend on each other should run at the same time.

(Start) -> /Access request form/ -> <Is the app on the pre-approved list?>
   --yes--> [Provision access] -> [Notify requester] -> (End)
   --no--> SPLIT
             branch A: [Manager approves?]
             branch B: [Security reviews data access?]
           JOIN (wait for both)
           -> <Both approved?>
                --yes--> [Provision access] -> [Notify requester] -> (End)
                --no--> [Notify requester with reason] -> (End)
   Timeout: if either branch has no answer after 3 working days, remind the approver;
            after 5, escalate to the approver's manager

Drawing the join explicitly forces a decision people skip: what happens when one branch approves and the other never answers. The timeout line answers it. The working-day counts here are illustrative; pick ones your team will actually honour.

3. CRM-to-billing sync: error paths and retries

Pattern: a system-to-system workflow with failure handling. This is the type of diagram where the happy path is maybe a third of the drawing.

(Start: opportunity marked closed-won in CRM)
  -> [Read account, contacts, line items]
  -> <Required billing fields present?>
       --no--> [Create task for deal owner: list missing fields] -> {Wait for fields updated} -> back to [Read ...]
       --yes--> [Find customer in billing system by CRM account ID]
  -> <Customer exists?>
       --yes--> [Update customer]
       --no--> [Create customer; write billing ID back to CRM]
  -> [Create subscription]
  -> <Billing API call succeeded?>
       --yes--> (End: synced)
       --temporary error (timeout, rate limit)--> [Retry with backoff, up to N times] -> back to [Create subscription]
       --permanent error or retries exhausted--> [Post to ops channel with record links] -> (End: needs human)

Two details matter. First, “find by CRM account ID” before “create” makes the workflow safe to re-run; a version that always creates a customer will produce duplicates the first time a retry fires after a call that actually succeeded. This property is called idempotency; see idempotency in workflows for why it matters. Second, the diagram distinguishes temporary from permanent errors. Retrying a validation error five times wastes five calls and delays the alert.

4. Renewal reminders: a time-based workflow

Pattern: waits as first-class steps. Many diagrams hide time in an arrow label; drawing waits as shapes makes the timeline readable.

(Start: subscription created, renewal date known)
  -> {Wait until 90 days before renewal}
  -> [Create renewal opportunity; assign account owner]
  -> {Wait until 60 days before renewal}
  -> <Renewal opportunity still open?>
       --no--> (End)
       --yes--> [Send owner a reminder with usage summary]
  -> {Wait until 30 days before renewal}
  -> <Renewal opportunity still open?>
       --no--> (End)
       --yes--> [Notify owner's manager]
  Cancel condition: if the subscription is cancelled at any point, stop the workflow

The 90/60/30-day spacing is an example, not a recommendation. The checks after each wait are the useful part: long-running workflows must re-read the current state after waking up, because the world has changed while they slept. The cancel condition is the other thing to draw; a reminder sent about a cancelled subscription is how customers learn your systems disagree.

5. Webinar follow-up: a branch on an external event

Pattern: routing on data that arrives from another system, with a fallback when it doesn’t arrive.

(Start: webinar ends)
  -> {Wait for attendance report from webinar platform, max 24 hours}
  -> <Report received?>
       --no--> [Alert marketing ops] -> (End)
       --yes--> for each registrant:
                  <Attended?>
                    --yes, stayed past a set point--> [Send recording + next-step email] -> <Account in target list?>
                                                         --yes--> [Create task for account's SDR]
                                                         --no--> [Add to nurture]
                    --yes, left early--> [Send recording]
                    --no--> [Send "sorry we missed you" + recording]
  -> (End)

The branch that shows up here and almost nowhere else: the report never arriving. Webinar, form and enrichment tools all fail to deliver sometimes. A diagram without that branch produces an automation that silently does nothing.

6. Expense claim: a swimlane diagram

Pattern: lanes per role, which shows handoffs and where work waits for someone.

Step	Employee	Manager	Finance	System
1	Submits claim + receipts			Checks receipts attached
2				Policy check: amount, category
3		Approves or returns with comment		Reminds after 2 working days
4	Fixes and resubmits (if returned)			Back to step 2
5			Reviews claims over the policy limit	Auto-passes claims under the limit
6				Queues for next payment run
7	Receives notification			Marks paid when payment confirmed

Swimlanes make one problem obvious: every time a row moves from one lane to another, work waits. In this illustrative process the claim changes lanes at almost every step, and the reminder in step 3 exists because manager approval is the handoff most likely to stall. The business process mapping examples guide uses this table format for six more cross-team processes.

Which diagram type for which job

You want to show	Use	Example above
A simple sequence with a few decisions	Basic flowchart	1
Independent steps that can happen at once	Flowchart with split and join	2
An integration between systems	Flowchart with error branches	3
A process that runs over days or weeks	Flowchart with wait shapes	4
Routing on data from another tool	Flowchart with fallback branch	5
Who does what, and where handoffs slow things down	Swimlane	6

Checklist before you automate from a diagram

Run through this before turning any of these into a working automation:

• Trigger is specific. “When a deal closes” becomes “when opportunity stage changes to closed-won”, including what happens if it changes back.
• Every decision has all its exits. Approve, reject, and the one people forget: no answer.
• Every wait has a timeout and a defined action when it expires.
• Every external call has a failure branch, with temporary and permanent errors handled differently.
• Re-running is safe. Look-up-before-create on any step that creates records.
• Long waits re-check state after they finish.
• There is an owner for the “needs human” end state, named in the diagram.

If several of these are missing, the process probably isn’t ready to automate yet; the workflow readiness rubric is a structured way to check.

A diagram drawn this way maps almost one-to-one onto a workflow in Automatite’s Workflow Builder: triggers, steps, branches, waits and error paths are all separate building blocks, so the error and timeout branches you drew become visible parts of the workflow rather than code hidden inside a step.

FAQ

What’s the difference between a workflow diagram and a process map? They overlap. A workflow diagram usually focuses on the sequence of steps and decisions for one piece of work. A process map often adds who performs each step, the systems used and measurements such as time per step, and may cover a wider process made of several workflows.

What tool should I draw workflow diagrams in? Any diagram tool that supports flowchart shapes and swimlanes works. If the diagram is a design for an automation, keep a text version like the ones above in the ticket or spec as well, so it can be reviewed and diffed without opening a drawing.

How detailed should a workflow diagram be? Detailed enough that two people would build the same automation from it. If someone has to ask “what happens if the approver is on holiday?”, that branch belongs in the diagram.