Workflow Diagrams: Symbols, Types and Examples
A workflow diagram maps who does what, in what order, and what happens when a step fails. Engineers reach for one when a process spans multiple people or systems: a deploy pipeline, an on-call escalation, a hiring loop. This guide covers the symbols that matter, when to use a workflow chart versus a flowchart or BPMN, swimlanes for role handoffs, three worked examples you can copy, the two mistakes that make most workflow diagrams useless, and how to generate one from a plain-English description.
What is the difference between a workflow diagram, a flowchart, and BPMN?
A flowchart models logic: a sequence of operations and decisions, usually executed by one actor or one program. A workflow diagram models work: the same boxes and arrows, but the steps are tasks performed by different people, teams, or systems, and the interesting information is the handoffs between them. If your diagram answers the question 'what does the code do,' it is a flowchart; if it answers 'who is blocked on whom,' it is a workflow chart.
BPMN (Business Process Model and Notation) is the formal end of the same spectrum. It adds a standardized vocabulary of events (message, timer, error), gateways (exclusive, parallel, inclusive), and pools for separate organizations, and BPMN 2.0 XML can be executed directly by engines like Camunda or Flowable. That rigor pays off when the diagram is the process definition. For everything else, full BPMN is overkill: nobody on your team should need to know what an event-based gateway is to understand your PR review process.
A practical rule: use a plain flowchart for single-actor logic, a workflow diagram with swimlanes for multi-actor processes you want humans to follow, and BPMN only when a workflow engine will execute the model or a compliance team requires the notation. Most engineering documentation lands squarely in the middle category.
What symbols are used in a workflow diagram?
You need six shapes, all inherited from standard flowchart notation. The terminator (rounded rectangle, sometimes an oval) marks the start and end of the process; every workflow diagram should have exactly one start and at least two ends, because real processes have failure exits. The process box (rectangle) is a single task: 'Provision laptop,' 'Run CI pipeline,' 'Page on-call engineer.' Write tasks as verb phrases, one action per box.
The decision diamond is where the path splits, and every diamond needs a question inside ('Tests pass?') and a label on every outgoing arrow ('yes,' 'no,' 'timeout'). An unlabeled arrow out of a diamond is the most common notation error in the wild. The document symbol (rectangle with a wavy bottom edge) marks an artifact produced or consumed: an offer letter, a postmortem doc, a signed contract. The data or input/output parallelogram marks information entering or leaving the process, such as a form submission or an API payload.
Two connectors round out the set. Solid arrows show sequence flow, the order work happens in. The off-page connector (a small circle or pentagon with a letter) lets you split a large workflow across pages or link into a subprocess without spaghetti arrows. Resist the urge to use more exotic shapes; a diagram a new hire can read without a legend beats one that flexes the full stencil.
How do swimlanes show ownership and handoffs?
A swimlane diagram partitions the workflow into horizontal or vertical bands, one per role or system: Hiring Manager, IT, HR; or Developer, CI, Reviewer. Each task box sits inside the lane of whoever performs it, so ownership is structural rather than a note in the corner. This is the single highest-leverage upgrade you can make to a workflow chart, because it makes two things visible that a flat diagram hides.
First, handoffs: every arrow that crosses a lane boundary is a point where work changes hands, which is where processes stall. If your onboarding workflow has an arrow crossing from HR to IT four times, you have found your bottleneck before measuring anything. Second, unowned steps: if a task does not fit cleanly into any lane, no one owns it, and in production that step silently does not happen.
Keep lanes to roles, not named individuals ('Reviewer,' not 'Priya'), and cap the count around five or six. Beyond that, split the process into a top-level workflow with subprocess references. Systems get lanes too: 'GitHub Actions' or 'PagerDuty' as a lane makes automated steps explicit instead of hiding them inside human tasks.
Three workflow diagram examples: onboarding, PR review, incident response
Employee onboarding is the canonical swimlane example because it crosses four lanes: HR, IT, Hiring Manager, and New Hire. The happy path runs from 'Offer signed' (start, HR lane) through 'Create accounts and provision laptop' (IT), 'Assign onboarding buddy and 30-day plan' (Hiring Manager), to 'Complete first-week checklist' (New Hire). The decision points are what make it a real workflow: 'Background check clear?' with a 'no' branch to 'Escalate to legal,' and 'Equipment delivered before day one?' with a 'no' branch to 'Ship loaner and log delay.'
A PR review workflow has three lanes: Author, CI, and Reviewer. Author opens the PR; CI runs lint, tests, and build; a diamond asks 'CI green?' with the 'no' branch looping back to Author. On green, the Reviewer lane picks up: 'Review within SLA?' branches to an auto-reminder task, and 'Changes requested?' loops back to the Author lane. The end states matter: 'Merged' and 'Closed without merge' are both terminators, and diagramming the second one forces a conversation about who is allowed to close stale PRs.
Incident response splits across On-call Engineer, Incident Commander, and Communications lanes. Alert fires (start), on-call acknowledges, and the first diamond is 'SEV1 or SEV2?': the SEV2 branch stays in the on-call lane as 'Mitigate and log,' while SEV1 crosses lanes to 'Page incident commander' and 'Post status page update.' Post-mitigation, the flow continues to 'Schedule postmortem within 48h,' which is the step most teams skip and therefore the step most worth putting in a box with an owner.
What are the most common workflow diagram mistakes?
Mistake one: diagramming only the happy path. A workflow chart where every diamond has a visible 'yes' branch and an implied 'no' is documentation theater. The failure paths are the whole point; the 3 a.m. version of your incident workflow is the one that matters. Audit your diagram by checking every decision diamond for at least two labeled exits, and every external dependency (vendor API, approver on vacation) for a timeout or escalation branch.
Mistake two: steps without owners. 'Approval received' is not a task, it is a wish; 'Engineering manager approves within 2 business days' is a task with an owner and an SLA. Swimlanes enforce this mechanically, but even in a flat diagram every process box should name a role. A related smell is the passive-voice box ('Laptop is provisioned'), which almost always means the author does not know who does the work, which means nobody does.
Two smaller offenders: crossing arrows that could be untangled by reordering lanes, and diagrams frozen as screenshots in a wiki. Keep the source file (draw.io XML, Mermaid) in the repo next to the process it describes, so the diagram changes in the same PR as the process. Tools with version history, such as AIDrawIO or a Git-tracked .drawio file, make it possible to see how the process evolved instead of arguing about it.
How to create a workflow diagram from a plain-English description
You have real options for authoring. draw.io (diagrams.net) is free and has the deepest shape libraries, but you place every box by hand. Mermaid gives you diagrams-as-code that render in GitHub and Notion, though its swimlane support is limited to flowchart subgraphs, which get awkward past three lanes. Lucidchart has the most polished collaborative swimlane editor but sits behind a per-seat subscription. AI generation is the fourth option: describe the process in prose and get an editable diagram, then fix the 10 percent the model got wrong instead of dragging shapes for an hour.
With AIDrawIO's workflow diagram generator (aidrawio.com/en/tools/workflow-diagram-generator), you write the process as you would explain it in Slack. For example: 'Create a swimlane workflow diagram with lanes for Author, CI, and Reviewer. Author opens a PR. CI runs lint, tests, and build. If CI fails, return to Author to fix. If CI passes, Reviewer reviews within 24 hours. If changes are requested, loop back to Author. If approved, Author merges. Include an end state for PRs closed without merging.' The output is draw.io XML, so you can refine it visually in AIDrawIO or open it directly in diagrams.net, and export SVG or PNG for docs.
The free tier allows 5 generations per hour with no account, which covers iterating on a single process diagram: generate, read it like a code review, tighten the prompt ('add a timeout branch when the reviewer misses SLA'), and regenerate. If you have an existing whiteboard photo of the process, you can upload the sketch and convert it into an editable vector diagram instead of redrawing it. Whichever tool you pick, the test of a good workflow diagram stays the same: every step has an owner, every diamond has a failure branch, and a new team member can execute the process from the diagram alone.
無料で試す Workflow generator
AI workflow diagrams. Describe in plain English, get draw.io XML in seconds. No account required.
よくある質問
What is the difference between a workflow diagram and a flowchart?
A flowchart models the logic of a single actor or program, while a workflow diagram models tasks performed by multiple people, teams, or systems and emphasizes the handoffs between them. Workflow diagrams typically add swimlanes so each step has a visible owner. The shapes are largely the same; the subject matter differs.
What are the basic symbols in a workflow diagram?
Six shapes cover almost every case: rounded terminators for start and end, rectangles for tasks, diamonds for decisions, wavy-bottom rectangles for documents, parallelograms for data input/output, and small connector circles for jumping between pages. Every decision diamond should have a question inside and a label on each outgoing arrow.
When should I use BPMN instead of a simple workflow diagram?
Use BPMN when a workflow engine like Camunda or Flowable will execute the model, or when a compliance or process team requires the standard notation. For processes that humans follow, a swimlane workflow diagram is easier to read and maintain. BPMN's event and gateway types add precision most teams never need.
How do I create a workflow diagram from a text description?
Write the process as plain prose, naming the lanes (roles), the steps in order, and each decision with its yes and no branches. Paste that into an AI diagram tool such as AIDrawIO's workflow diagram generator, which outputs editable draw.io XML you can refine in diagrams.net and export as SVG or PNG. Alternatively, write it as Mermaid flowchart code if you want the source rendered in GitHub.
What makes a workflow diagram effective?
Three properties: every step names an owning role, every decision point has labeled branches including failure and timeout paths, and the source file lives somewhere versioned so the diagram evolves with the process. If a new team member can execute the process from the diagram alone, it works.