A flowchart is a diagram that represents a process or workflow as a sequence of steps, using standardized shapes connected by arrows. Each shape has a specific meaning: ovals mark where the process starts and ends, rectangles show actions to be performed, diamonds show decision points where the path branches, and arrows show the direction of flow.
Flowcharts are one of the oldest and most widely used forms of diagram — they appear in business process documentation, software engineering, manufacturing, healthcare, and education. The reason is simple: they make processes that live in people's heads or in dense written procedures visible and readable at a glance.
Why Flowcharts Work
The power of a flowchart isn't just visual. When you try to draw a process that you thought you understood, you quickly discover where the gaps are: the step nobody owns, the decision that nobody actually defined, the path that leads nowhere.
A flowchart forces precision. You can't draw an arrow from one step without knowing where it goes. You can't leave a diamond with one exit. The constraint of the format surfaces the ambiguity hiding in natural language descriptions.
This is why organizations use flowcharts before they build things — whether that's a software system, a customer service process, or a manufacturing line. Errors caught on a whiteboard cost almost nothing. Errors caught in production cost a lot.
Flowchart Symbols and What They Mean
| Symbol | Shape | Meaning |
|---|---|---|
| Terminator | Oval | Start or End of the process |
| Process | Rectangle | An action, task, or step |
| Decision | Diamond | A yes/no or true/false branch |
| Data | Parallelogram | Input received or output produced |
| Flow line | Arrow | Direction from one step to the next |
| Document | Wavy-bottom rectangle | A document produced or used |
| Database | Cylinder | Data stored in a database or file |
| Connector | Circle | Continues on another part of the same diagram |
| Off-page reference | Pentagon | Continues on a different page |
| Manual input | Slanted-top rectangle | Data entered manually by a person |
The first five shapes — terminator, process, decision, data, and flow line — cover roughly 95% of all flowcharts you'll encounter. The rest are specialized and appear mainly in technical documentation.
Types of Flowcharts
Not all flowcharts are structured the same way. Different situations call for different formats:
Process flowchart. The basic format: steps flow top to bottom or left to right, with decision branches. Used for documenting any linear or branching process.
Swimlane flowchart. The same flow, but divided into horizontal or vertical lanes — one per person, team, or system. Shows who is responsible for each step and makes handoffs between parties visible. Useful when multiple people or departments are involved.
Data flow diagram (DFD). Focuses on how data moves through a system: where it comes from, what processes transform it, where it's stored. Used in software and systems analysis.
Workflow diagram. A looser, less rigidly standardized version of a flowchart, often used in business process modeling where the emphasis is on steps and ownership rather than technical precision.
Cross-functional flowchart. Similar to a swimlane, used specifically to show how work moves across organizational functions.
For most purposes, a standard process flowchart or swimlane diagram covers the need. The more specialized types (DFD, BPMN) are tools for specific professional contexts.
Real-World Flowchart Examples
Customer Support Ticket Flow
A support team uses a flowchart to document how incoming tickets are handled:
- Start: Customer submits a ticket
- Decision: Is it a billing issue? → Yes: route to billing. No: continue
- Decision: Is it a technical issue? → Yes: route to tech support. No: continue
- Process: Assign to first available general support agent
- Process: Agent acknowledges within SLA
- Decision: Resolved in first contact? → Yes: close ticket. No: escalate
- End: Ticket closed and customer notified
Without the flowchart, the same process is described in a multi-page procedure document that agents rarely read consistently. The diagram reduces it to a one-page reference.
Software Deployment Process
A development team maps their release process:
- Developer merges code to main branch
- CI system runs automated tests
- Decision: Tests pass? → No: notify developer, reject merge. Yes: continue
- Build artifact is created and pushed to staging
- QA team reviews on staging
- Decision: QA approved? → No: return to development. Yes: continue
- Deployment to production with monitoring enabled
- End: Release complete
The flowchart makes the gates explicit — nothing goes to production without passing both automated tests and QA review.
New Employee Onboarding
HR documents the onboarding sequence:
- Employee accepts offer
- IT provisions accounts (email, tools, access)
- Decision: Remote or in-office? → Different welcome sequences
- Manager assigns onboarding buddy
- Week 1: orientation meetings, tool training
- Week 2-4: role-specific training
- 30-day check-in with HR
- End: Onboarding complete
By mapping this as a flowchart, the team can see that the remote vs. in-office decision happens before accounts are provisioned — which means IT needs to know the work location before starting.
E-commerce Order Processing
An online store maps the path from order placement to delivery:
- Customer places order
- Decision: Payment successful? → No: notify customer, order cancelled. Yes: continue
- Decision: Items in stock? → No: notify customer, offer alternatives. Yes: continue
- Order sent to warehouse for picking and packing
- Decision: Express shipping? → Different carrier routes
- Package shipped, tracking number sent to customer
- End: Delivery confirmed
This flowchart reveals that stock is only checked after payment — a common design choice, but one worth making consciously.
How to Create a Flowchart
Step 1: Define the scope. What's the start event and what's the end state? Be specific. "Customer service process" is too broad. "How a tier-1 support ticket moves from submission to closure" is a scope you can actually draw.
Step 2: List every step. Before drawing, write out all the actions and decisions as a numbered list. This prevents you from discovering mid-drawing that you forgot a step.
Step 3: Identify decision points. Go through your list and mark every step that has more than one possible outcome. These become diamonds in the diagram.
Step 4: Draw the flow. Start from the beginning, place shapes, connect them with arrows. Every diamond needs labeled exit arrows (Yes/No, or descriptive labels).
Step 5: Check for completeness. Every path should lead somewhere. A decision branch that ends without reaching the End terminator is a gap in your process.
Step 6: Validate with people who do the work. The person who designed the process and the person who executes it often have different mental models. Show the flowchart to someone who does this work and ask if it's accurate.
Common Mistakes
Using the wrong shape. A diamond means "decision." If you use a diamond for a regular action because it looks better in that position, you're misleading the reader into expecting a branch.
Unlabeled decision arrows. Every exit from a diamond needs a label. Without labels, readers have to guess which path is Yes and which is No.
Crossing arrows. When arrows cross frequently, the diagram becomes hard to follow. Reorganize the layout so the main flow runs in one direction.
No start or end. A flowchart without a clearly labeled Start and End isn't a flowchart — it's a diagram with no defined scope.
Too much detail. A step that needs five lines of explanation is probably doing more than one thing. Break it up.
Flowchart vs. Other Diagram Types
| Situation | Better Tool |
|---|---|
| Need to show who does what in a multi-team process | Swimlane diagram |
| Exploring ideas without a defined sequence | Mind map |
| Showing how software components connect | System architecture diagram |
| Showing how a database is structured | Entity-relationship diagram (ERD) |
| Showing messages between systems over time | Sequence diagram |
| Planning a project with tasks and deadlines | Gantt chart |
Use a flowchart when you need to document a process that has a clear sequence and one or more decision points. Use a different tool when the question is about structure, timing, ownership, or exploration.
Frequently Asked Questions
What software do I use to make a flowchart? draw.io is free and has no feature limits. Lucidchart has a free tier with real-time collaboration. CodePic is free, unlimited, and can generate flowcharts from plain-language descriptions using AI.
How many shapes should a flowchart have? There's no rule, but if a flowchart has more than 20-30 shapes and you can't fit it on one screen at a readable size, consider breaking it into sub-processes with connector symbols.
What's the difference between a flowchart and a process map? The terms are used interchangeably in most contexts. Technically, "process map" often implies a less rigidly standardized diagram with more emphasis on stakeholders and metrics, but in everyday usage they mean the same thing.
Should flowcharts flow top-to-bottom or left-to-right? Top-to-bottom is more common and feels more natural to most readers. Left-to-right is sometimes used for processes that have a strong "time passes" quality. Either works — what matters is consistency within a single diagram.
