121 templates · page 1 of 2
Flow & Process diagram templates
Flowcharts, BPMN, swimlanes, decision trees, PRISMA, CONSORT.
Flowchart
Classic flowchart with decisions, IO and processes.
MermaidSwimlane / Cross-functional
Process responsibilities organised by role.
MermaidDecision Tree
Decision tree rendered via Graphviz DOT for clean splits.
Graphviz (DOT)BPMN — Insurance Claim
End-to-end insurance claim approval with a gateway and tasks.
BPMN 2.0Flowchart — interactive + styled
Click events, animated edges, classDef-based theming, linkStyle, icon shapes via Iconify.
MermaidPlantUML — Activity Beta (full feature set)
Activity beta showcase — swimlanes, partitions, fork/join, kill/detach/stop, repeat-while, coloured branches, notes.
PlantUMLBPMN — Loan Approval
Loan-approval process with exclusive gateway, service task, and message events.
BPMN 2.0BPMN — Pizza Order
The canonical BPMN teaching example — pizza ordering with parallel cook + bake.
BPMN 2.0Graphviz — Petri Net
Workflow Petri net with places (circles) and transitions (bars).
Graphviz (DOT)Blank Canvas
A single starter box on an empty canvas — drag from the palette to build.
WeaveApproval Workflow
Request → Review → Decision → Approve / Reject path.
WeaveUser Onboarding
Signup → Email verify → Profile setup → First task completed.
WeaveIncident Runbook
Alert → Triage → Decision tree (rollback / hotfix / escalate).
WeaveML Training Pipeline — with Feedback Loop
Data → preprocess → train → evaluate → deploy, with a feedback loop.
WeaveOrder State Machine
Pending → Paid → Shipped → Delivered with cancellation paths.
WeaveState — Pull Request
Pull-request state machine: open → review → merged / closed.
MermaidFlowchart — Incident Response
Detect → triage → mitigate → postmortem.
MermaidFlowchart — CI/CD
Push → CI → tests → review → deploy stages.
MermaidGitOps Deployment Flow
Push to Git → CI image build → manifests in repo → operator reconciles cluster.
MermaidCanary Deployment
Progressive rollout with metric gates and automatic rollback.
MermaidBlue-Green Deployment
Switch traffic between identical blue / green stacks in one cutover.
WeaveFeature Flag Decision
Runtime feature-flag evaluation with audience targeting.
MermaidFine-Tuning Workflow
From raw text to a deployed fine-tuned model with evaluation gates.
MermaidGDPR Data-Subject Rights
Process flow when a user invokes access / erasure / portability rights.
Mermaid5-Whys Root Cause
Iterative 5-whys analysis for an outage.
Graphviz (DOT)User Flow — Sign Up + Onboarding
Landing → sign-up → verify → tour → first action.
MermaidAccessibility Decision Flow
Pick the right semantic element / pattern for a UI need.
MermaidGame Loop
Fixed-timestep simulation loop with variable-rate render.
MermaidKYC / AML Onboarding
Customer onboarding with identity verification, screening and risk scoring.
MermaidClinical Decision Support Flow
EHR event triggers CDS hook, returns suggestion card to clinician.
MermaidPatient Consent Flow
Granular consent capture, attestation, and downstream policy enforcement.
MermaidMedication Reconciliation
Admission med-rec workflow comparing home meds vs admission orders.
MermaidContract Review Workflow
Incoming contract → triage → playbook check → negotiation → execution.
MermaidE-Discovery EDRM Pipeline
Electronic Discovery Reference Model phases from identification to presentation.
MermaidCompliance Audit Workflow
Plan → fieldwork → findings → remediation → re-audit cycle.
MermaidAzure DevOps Pipeline
Multi-stage YAML pipeline — build → test → deploy across environments.
MermaidMRP — Material Requirements Planning
Master schedule → BOM explosion → net requirements → purchase / produce orders.
MermaidJust-In-Time Pull Flow
Customer demand pulls work upstream via kanban signals.
MermaidRegulatory Drafting Pipeline
From green paper through consultation to enacted regulation.
MermaidTreaty Ratification Flow
Negotiation → signature → ratification → entry into force.
MermaidAudio Buffer Processing
Real-time audio callback — fill / process / play.
MermaidPDCA — Deming Cycle
Plan-Do-Check-Act continuous-improvement cycle.
Graphviz (DOT)DMAIC — Six Sigma
Define → Measure → Analyse → Improve → Control with tollgates.
MermaidNIST Incident Response
NIST SP 800-61 four-phase incident response loop.
MermaidLLM Training Stages
Pretraining → SFT → preference data → RLHF / DPO → deployment.
MermaidSales Pipeline Stages
B2B pipeline from prospect to closed-won with stage exits.
MermaidPerformance Review Cycle
Bi-annual review cycle with goal-setting, mid-cycle and review.
MermaidContact Tracing Workflow
Index case → contacts → testing → quarantine / isolation cycles.
MermaidMLOps Data Pipeline
Raw → curated → features → splits with lineage and tests.
MermaidCode Review Flow
Author → reviewers → checks → merge with re-review loop.
MermaidTrunk-Based Development
Short-lived branches, feature flags, continuous integration into trunk.
MermaidCross-Docking Operation
Inbound trailers staged briefly then loaded directly to outbound — no storage.
MermaidInsurance Claim Lifecycle
FNOL through investigation, decision, payment and possible litigation.
MermaidMining Project Lifecycle
Exploration through closure across decades for a mineral project.
MermaidF1 Race-Strategy Decision Tree
Pit-window decision branches driven by tyre, weather and SC.
MermaidUN Sanctions Process
From situation referral through resolution, designation and listing.
MermaidDAO Governance Flow
On-chain proposal lifecycle from forum thread to execution.
MermaidCivil Court Process
Civil dispute from complaint through trial, appeal and enforcement.
MermaidUS Bill Becomes Law
Legislative pathway from introduction to enacted law.
MermaidElection Day Workflow
Voter arrival through ballot tabulation with chain of custody.
MermaidEmergency Response Phases
Mitigation → Preparedness → Response → Recovery emergency-management cycle.
Graphviz (DOT)Recipe — Sourdough Bread
Long-fermentation sourdough timeline from levain to loaf.
MermaidUS Patent Prosecution
From provisional filing through office actions to issued patent.
MermaidClassic Flowchart
Standard flowchart symbols — terminator, process, decision, document, database.
WeaveSwimlane Process — Lead to Live Customer
Cross-functional process across Sales / Engineering / Support lanes using containers.
WeaveBPMN-style Process
Process with start / task / gateway / end using flowchart shapes.
WeaveBPMN — Claim Handling
Insurance claim process using the new native BPMN palette (start/task/gateway/end).
WeaveBPMN — Procurement
Procurement with parallel approval and a timer-driven escalation event.
WeaveBPMN — User Onboarding
Multi-channel onboarding with message events and a verification gateway.
WeaveIncident Response Bridge
Live incident bridge roles + comms channels + decision-making swimlanes.
WeaveDecision Tree — Loan Eligibility
Three-level decision tree with leaf outcomes.
WeaveBDD Feature Flow
Given → When → Then. Edge labels carry the spec phrases.
WeaveClassic flowchart (with proper symbols)
Terminator → Input → Process → Decision → Document — using the right shape for each step.
WeaveHello Pikchr
Minimal box → arrow → oval flow — the canonical intro.
PikchrTwo-box hand-drawn flow
Minimal Excalidraw JSON — two rectangles and an arrow, sketchy rough-pen rendering.
ExcalidrawDecision diamond (sketchy)
Diamond + two outcomes — the kind of figure that lives in a half-finished whiteboard photo.
ExcalidrawPikchr — feedback loop
Closed-loop control diagram with sensor and actuator.
PikchrBPMN — online payment
Customer payment flow with gateway and validation gateways.
BPMN 2.0SVGBob — pipeline boxes
ASCII pipeline rendered to SVG.
SVGBob (ASCII)Website Sitemap
Information-architecture tree of a website's pages and sub-pages.
WeaveWeave — Order to Cash (Swimlanes)
Customer, sales, warehouse and finance lanes carrying an order from placement to cash applied.
WeaveGRAFCET — Batch Reactor Heat-Hold-Cool
A charge-heat-hold-cool-discharge batch that carries both branch shapes at once: a simultaneous divergence brings the jacket to temperature while the agitator ramps to shear speed, one convergence releases the hold, and an alternative divergence on the assay sends a failed batch round a rework hold rather than out of the vessel.
GRAFCET / SFCGRAFCET — Rollover Car Wash Gantry
A rollover wash whose side and roof brushes are genuinely concurrent, drawn with the double bar that says so and the convergence that holds the rinse until both are parked, then an alternative divergence on the selected programme whose two paths rejoin on the dryer.
GRAFCET / SFCCard Authorisation — the Reference Interaction
The one to copy. A checkout that calls out to a card vault, posts to a ledger and notifies the storefront, with a payment saga created for the transaction and destroyed when it ends. Every call is answered by the participant that made it, on every branch; the `alt` covers its declared domain exactly with no overlap; the two `par` branches address different lifelines; the saga is used only between its create and its destroy. Reports clean, and every one of the seventeen checks says what it covered.
Sequence & interactionTeaching Case — A Reply That Went to the Wrong Participant
The same interaction with one word changed: the card vault answers the order service instead of the saga that called it. Fourteen arrows, fourteen rows, the same labels — one arrowhead lands one column further along. The saga is left blocked forever on an answer that went elsewhere, and the order service receives an answer to a call it never made. No runtime could produce this interaction, and no tool that draws what it is handed can tell you so.
Sequence & interactionTeaching Case — A Message to a Lifeline That No Longer Exists
A session is closed and then used. In every tool that draws lifelines the full height of the figure, the arrow lands on an ordinary dashed line and looks exactly like a message to a live object — which is why the defect survives review. Here the lifeline stops at the destruction cross, so the message visibly lands on nothing AND the panel says which line destroyed it. The second finding is its consequence: the call that message opened can never be answered.
Sequence & interactionTeaching Case — Two Services Waiting on Each Other
Four ordinary arrows and two ordinary activation bars. Inventory calls pricing while pricing is mid-call to inventory, and neither call is ever answered — so each is waiting for a reply that cannot arrive until it replies first. The picture is a deadlock and it is indistinguishable from a working handshake. The engine also refuses the false positive next door: a callback that IS answered — one service calling back into another mid-call and getting a reply — is ordinary and this check says nothing about it.
Sequence & interactionTeaching Case — Answered on One Branch Only
Every branch of the `alt` has arrows in it, so every branch looks answered. One of them is not: on the retry path the service never replies to the client that called it, and the client waits forever. This is the check that most needs narrowing to be worth having — written as "the call was made outside the fragment and answered inside it" it fires on the commonest correct pattern in the notation, so it fires only when at least one branch fails to answer a call the fragment inherited.
Sequence & interactionTeaching Case — Branches That Overlap, and an Input With Nowhere to Go
The one check here that would cry wolf constantly if it were not gated, and the gate is the point. Free-text guards parse as ordinary values, so two prose branches look disjoint and exhaustive of nothing — which is why this check runs only on a fragment that declares what it is testing and over what domain. Given that declaration it becomes exact: two branches that both accept the same scores, and a band of scores no branch accepts at all. Both draw as a fragment with arrows in every branch.
Sequence & interactionTeaching Case — Two Concurrent Branches Addressing One Service
Both branches of the `par` run at the same time and both send to the ledger, so as drawn the order of arrival is not determined — and neither branch shows the other. The engine reports the ledger and stays silent about the forking lifeline, which is in every branch by construction as both the sender and the recipient of the replies; getting that narrowing wrong makes the check fire on every realistic `par`. A lifeline that IS safe to address concurrently says so with `concurrent`, and is then exempt by declaration rather than by this engine guessing which services are stateless.
Sequence & interactionTeaching Case — Arrows That Never Said What They Meant
The most important template in this set, and nothing in it is wrong. A document imported from a notation whose arrows carry no semantics — `->>` and `-->>` are drawn differently and mean whatever the author had in mind — is read as stating nothing, and the checks that depend on a call stack report a GAP naming the line they stopped at. They do not guess. An engine that read those arrows as calls and replies would produce a complete, confident analysis of an interaction the document never described, which is worse than no analysis at all. Rewrite the arrows as `->`, `reply` and `async` and the same document is fully checked.
Sequence & interactionOrder Lifecycle — the Reference Machine
The one to copy. Every state is reachable from the declared initial state, every transition names states that exist, every fork carries a guard that distinguishes it, every non-final state has a way out, and a run can reach a final state. Retries and cancellations are ordinary cycles and the engine says nothing about them, because a loop is not a defect. Reports clean, and every one of the ten checks says what it covered.
State machine (FSM)Teaching Case — An Arrow to a State That Does Not Exist
One character changed: the transition out of `Paid` goes to `Shipd`. Every tool that draws what it is handed omits that arrow entirely — the renderer this engine replaces did `if (!a || !b) continue;` — so the figure showed a complete machine with one fewer edge, and nothing anywhere said an edge was missing. Here the arrow is drawn to a dashed box carrying the name that does not exist, and the reachability checks report a GAP rather than blaming the states the missing edge would have reached.
State machine (FSM)Teaching Case — A Machine and a Coin Toss
Two transitions leave `Review` on the same event and nothing tells them apart. The document does not say which one runs, so this is not a state machine: it is a state machine and a coin toss, and it draws as two perfectly ordinary arrows leaving one box. The engine also refuses the false positive next door — the fork out of `Draft` carries a guard on each branch, which makes it deterministic, and the engine says nothing about it.
State machine (FSM)Teaching Case — A State No Run Can Ever Be In
`Archived` is declared, labelled and drawn like every other state, and nothing enters it. No run of this machine can ever be in it — it is dead code with a box around it — and there is nothing in the picture to say so. The engine names it and dashes its outline, so the figure carries the finding rather than only the panel.
State machine (FSM)Teaching Case — A Deadlock Drawn as an Ordinary Box
`Held` is not marked final and has no transition out, so a run that arrives there stops and the machine has not finished. That is a deadlock, and it is drawn as a rounded box exactly like the states around it — the same shape, the same stroke, in the same row as the state that does finish. Note what the engine does NOT say: a final state IS reachable, by the other branch, so the machine can terminate and this is one stuck path rather than a machine that never ends.
State machine (FSM)Teaching Case — The Comment That Split the Figure From the Panel
Nothing in this document is wrong, and it is here because of what it used to do. There were two hand-written parsers for this notation — one for the drawing, one for the analysis panel — and the drawing's transition rule was anchored with a trailing `$` where the panel's was not. A transition ending in a comment was dropped from the FIGURE and kept in the PANEL, so the picture showed a machine with one fewer arrow than the text beside it described, both looking internally consistent, and nothing anywhere saying they were different machines. There is one parser now, and both read it. Reports clean.
State machine (FSM)Teaching Case — Two Boxes With One Name
`Cancelled` and `Void` are different states with the same label, so the figure prints one name twice. A reader cannot tell which arrow goes where, and a transition between the pair is indistinguishable from a self-transition on either of them — a defect that lives entirely in the drawing and cannot be seen by reading the source, which is where every reviewer looks.
State machine (FSM)Ladder - Signalled Junction Sequence
Eight rungs freeze a junction two seconds into its four-second amber: the 30 s green TON is done, the amber TON is still timing, the 25 s red TON has never been enabled, so only the amber lamp is lit and the engine names the green lamp, the red lamp and the unstarted red timer as never energised at this instant.
Ladder logic (PLC)Event Storm — Motor Insurance Claim
First notification of loss through assessment to settlement, showing a single validation command that fans out into an accept and a decline event.
Event storming