Flowcharts

The flowchart is the oldest and most widely understood diagram in software and business. This page teaches the symbols, walks through two complete examples, and lists when a flowchart is the right tool.

1. What a Flowchart Is

A flowchart shows the steps of a process and the decisions between them, using a small set of standard shapes joined by arrows. Anyone can read one: developers use them to plan algorithms, analysts to document business procedures, and support teams to write troubleshooting guides. The symbols were standardised by ANSI in the 1960s and later as ISO 5807.

2. Notation

Most flowcharts need only four shapes: the rounded terminator for start and end, the rectangle for a process step, the diamond for a decision with labelled exits, and the parallelogram for input or output. The others help larger charts: a predefined process points to a chart drawn elsewhere, a connector joins lines without crossing the page, and the cylinder marks stored data. Arrows always show the direction of control.

3. Example 1: Online Shop Checkout

Walkthrough: the flow starts, reads the cart, and asks whether every item is in stock. If not, it shows a message and loops back to the cart. If yes, it takes payment. An approved payment creates the order and ends. A declined payment checks a counter: under three tries, ask for a new card and retry; otherwise cancel. The two loops show how flowcharts express repetition with an arrow going back up, and the counter shows how a loop is kept from running forever.

4. Example 2: Password Reset with Swimlanes

Swimlanes add who to what. Each horizontal lane belongs to one actor. The user enters an email; the web app checks it. Known addresses get a token and the email service sends a link; the user opens it and sets a new password. Unknown addresses follow the "no" path to the same confirmation message, a deliberate security choice that the chart makes visible. Handoffs between lanes are where delays and bugs usually hide.

5. How to Draw a Good Flowchart

• One start, clear ends. Every path should reach a terminator; a dead end is a bug in the process.
• Label every decision exit. Write the question in the diamond and "yes"/"no" (or the values) on each arrow.
• Keep the main path straight. Draw the happy path down the middle and branch exceptions to the side, as in Example 1.
• Use verbs in process boxes. "Take payment", not "Payment".
• Split big charts. Past about 15 to 20 shapes, move a section into a subroutine box and draw it separately.
• Avoid crossing lines. Rearrange shapes or use connectors instead.

6. Diagrams as Code

The checkout example in Mermaid flowchart syntax. It renders in GitHub and GitLab Markdown, the Mermaid Live Editor, and many documentation tools; ([ ]) is a terminator, [/ /] input/output, { } a decision.

flowchart TD
    A([Start]) --> B[/Read cart/]
    B --> C{All in stock?}
    C -- no --> D[Show out-of-stock] --> B
    C -- yes --> E[Take payment]
    E --> F{Approved?}
    F -- yes --> G[Create order] --> H([End])
    F -- no --> I{Tries < 3?}
    I -- yes --> J[/Ask new card/] --> E
    I -- no --> K[Cancel checkout] --> H

7. Pros and Cons

Pros

• Readable by almost anyone, with no training.
• Few symbols to learn.
• Makes decisions, loops and missing branches obvious.
• Good for algorithms, procedures and troubleshooting guides.
• Swimlanes expose handoffs between people or systems.
• Easy to draw on a whiteboard or as Mermaid code.

Cons

• Large processes become sprawling and hard to maintain.
• Shows control flow, not data structures or system structure.
• Weak at concurrency and events; parallel work is awkward.
• No formal semantics, so styles vary between authors.
• Easily drifts out of date with the real process or code.

When to use: explaining a procedure or algorithm with clear decisions, onboarding, or agreeing a business process. When not to: describing data movement (use a data flow diagram), object structure (use UML class diagrams), concurrent workflows (use activity or BPMN diagrams) or object lifecycles (use state machines).

8. Related Diagrams

• Data Dictionary — defines the data that flows between steps
• Data Flow Diagrams — show how data moves rather than control
• Context Diagrams — the system and its external entities at a glance
• State Machine Diagrams — states and transitions of one object
• Interaction Overview Diagrams — flowchart-like control flow between interactions in UML
• UML Diagrams — the full family of UML diagram types

9. Further Reading

• ISO 5807:1985, Information processing — Documentation symbols and conventions for data, program and system flowcharts.
• Mermaid documentation, “Flowcharts — Basic Syntax” (mermaid.js.org).