Data Flow Diagram Examples: Context Diagram, Level 0 and Level 1

A data flow diagram (DFD) shows how information moves through a system: where it comes from, what transforms it, where it is stored and where it goes. It says nothing about timing, loops or which server runs what, and that is its strength. A DFD is the quickest way to agree on what data a system handles, which is why it shows up in requirements work, privacy reviews and threat modeling.

This post covers DFD symbols in the two classic notations, then works through one example, an online store, at three levels: the context diagram, level 0 and level 1. It also explains the naming confusion around "level 0", the balancing rule that keeps levels consistent, and the mistakes reviewers look for.

DFD symbols

DFDs use four elements. Two notations dominate, both from the structured analysis books of the late 1970s: Yourdon and DeMarco, and Gane and Sarson.

The notations are equivalent; pick one and keep it. Many modern tools draw data stores as cylinders, which readers recognize instantly. Whatever you choose, add a legend.

The rules that make a DFD valid

1. Every process has at least one input and one output. A process with only inputs is a black hole; one with only outputs is a miracle.
2. Data moves only through processes. No flow goes directly from an external entity to a data store, from one store to another, or between two external entities.
3. Flows carry names that describe data, such as "order details" or "payment result", not actions such as "send" or "check".
4. Processes are named as verb plus object: "Take order", "Fulfil order".
5. Each process is numbered, and its decomposition repeats the number: process 1 becomes 1.1, 1.2 and 1.3.

Levels, and the level 0 confusion

A DFD is drawn top-down, in levels of increasing detail:

• The context diagram shows the entire system as a single process, surrounded by every external entity and the flows between them. It defines the boundary.
• The next level opens that single process into its major processes, adds the data stores, and keeps the same external flows.
• Lower levels open individual processes further, as far as anyone needs.

Here is the confusion: some textbooks and tools call the context diagram "level 0" and its first decomposition "level 1", while others, following older structured analysis practice, treat the context diagram as its own level and call the first decomposition "diagram 0" or "level 0". Neither is wrong. This post uses the second convention: context diagram, then level 0, then level 1. Whatever you use, write it on the diagram.

The example: an online store

An online store takes orders from customers, charges them through a payment provider, and sends pick lists to a warehouse that ships the goods.

Context diagram

One process, "0 Online store", and three external entities:

That is the whole system from the outside. Anyone can review it in a minute, and it already answers important questions: which organizations receive customer data, and which systems we depend on.

Level 0

Open the online store into three processes and two data stores:

1. Take order receives order details from the customer, reads prices from D2 Products, writes the order to D1 Orders, and sends a payment request on to process 2.
2. Process payment sends the payment request to the payment provider, receives the payment result, updates the order in D1 Orders, and passes paid orders to process 3.
3. Fulfil order reads paid orders, sends the pick list to the warehouse, receives shipment status, and sends the order confirmation to the customer.

Every external flow from the context diagram appears again at level 0, connected to the same entities. That is balancing, and the diagram below makes it visible.

Level 1

Each level 0 process can be opened further. Process 1, Take order, at level 1:

The inputs and outputs of 1.1 to 1.3, taken together, must match the inputs and outputs of process 1 at level 0. Draw each level 1 explosion as its own diagram, with the parent process number in the title.

Balancing: the rule reviewers check first

A child diagram is balanced when the data flows entering and leaving it equal the flows entering and leaving its parent process. If level 0 shows a flow "refund request" that the context diagram does not, one of them is wrong: either the system has an interface nobody agreed on, or the context diagram is incomplete. Balancing is what makes DFD levels trustworthy as a set, and it is easy to check by listing the external flows of each level side by side.

Common mistakes

• Drawing a flowchart. Decisions, loops and "then" arrows belong in a flowchart or a BPMN diagram. A DFD shows data, not control.
• Unnamed flows. An arrow without a label tells the reviewer nothing; name the data it carries.
• Too many processes per diagram. More than about seven to nine processes on one level is hard to read. Group them, and open the groups at the next level.
• Data stores that only receive data. If nothing ever reads a store, why does it exist? If nothing writes to it, where does its data come from?
• Mixing levels. Showing detailed subprocesses next to high-level processes on the same diagram breaks the hierarchy.

DFDs, flowcharts and architecture diagrams

DFDs are the standard input for threat modeling: add trust boundaries to a level 0 diagram and you have the basis for a STRIDE review, as the threat modeling data flow diagram post shows. They are equally useful for privacy work, where the GDPR data mapping diagram traces personal data through the same kind of flows.

The DFD levels diagram

How to read it:

• The external entities stand in the middle: Customer, Payment provider and Warehouse. Both diagrams connect to them.
• The left frame is the context diagram: one process, 0 Online store, with six named flows to the entities.
• The right frame is level 0: Take order, Process payment and Fulfil order, with the Orders and Products data stores.
• Balancing is visible: each external flow on the left reappears on the right, now attached to the process that handles it.
• The Markdown block is the legend and the numbering convention.

Drawing DFDs that survive review

• Name every flow with a noun. Most review comments on DFDs are about unlabeled or vaguely labeled arrows.
• Number processes consistently across levels, so a reader can trace 1.2 back to 1.
• Keep external entities in the same positions on every level; it makes balancing easy to see.
• Add a legend for your notation, especially if you mix classic symbols with cylinders for data stores.

For the notation of other diagram types, see the flowchart-style incident response example and the BPMN diagram example.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add three Core Box nodes in a middle column for Customer, Payment provider and Warehouse.
3. Add a Core Frame on the left named Context diagram, with one Shape from the Core pack using the Ellipse variant for 0 Online store.
4. Add a second Core Frame on the right named Level 0, with three Ellipse Shape nodes for the processes and two Shape nodes using the Cylinder variant for D1 Orders and D2 Products.
5. Draw the flows as labeled edges, with the same labels on both sides of the entities.
6. Add a Markdown block from the Core pack with the legend and numbering convention.

The example uses 12 diagram nodes, within the Free plan.

FAQ

What are the four symbols of a data flow diagram? External entities, processes, data stores and data flows. Yourdon and DeMarco draw processes as circles and stores as parallel lines; Gane and Sarson use rounded rectangles and open-ended rectangles.

What is the difference between a context diagram and a level 0 DFD? A context diagram shows the whole system as a single process with its external entities. The next level opens that process into major subprocesses and data stores. Some sources call the context diagram level 0, so state your convention.

What does balancing mean in a DFD? The data flows entering and leaving a child diagram must match the flows of its parent process. It ensures that the levels describe the same system.

How is a DFD different from a flowchart? A DFD shows what data moves where and how it is transformed, without order or decisions. A flowchart shows the sequence of steps and the decisions between them.

How many levels should a DFD have? As many as readers need. Most systems are well described by a context diagram and level 0, with level 1 diagrams only for processes that are complex or sensitive.

Start free — one seat, no credit card.