How to Create a Data Flow Diagram: A Practical Guide

By the Diagramium team · 2026-08-13 · 7 min read

To create a data flow diagram, identify the external entities that send or receive data, the processes that transform it, and the data stores that hold it — then draw a labelled arrow for every movement between them. Name each arrow with the data that travels, not the action, and the diagram will answer where information comes from, what changes it, and where it ends up.

Live interactive diagramUse the player controls to follow the steps

Sign in with Google, explainedPlaying silently in this guideWatch with narration

This compact player stays quiet while you read. Open the full presentation when you want narration and the complete walkthrough.

When a data flow diagram is the right choice

A data flow diagram (DFD) shows information moving. It deliberately says nothing about order, timing or control flow — that omission is the point. A DFD is the right artefact when the question is about the data itself:

A design review. Which system holds the customer record, and how many copies exist?
A privacy or compliance assessment. Where does personal data enter, where is it stored, and what crosses a boundary you do not control?
An integration. Two systems must exchange data and nobody can name exactly what fields travel in each direction.

If your question starts with "and then what happens?", you want a flowchart or a sequence diagram. A DFD has no "then".

A data flow diagram has no time axis. If the order matters, you are drawing the wrong thing.

The four elements, and the rules that bind them

A DFD uses exactly four elements. The discipline is in the rules about how they may connect.

External entity. A source or destination outside the system — a customer, a partner API, a regulator. Drawn as a square. You do not control it and you cannot change it.
Process. Something that transforms data. Drawn as a circle or rounded box. Name it verb-first: Validate order, Score candidates.
Data store. Somewhere data rests — a table, a file, a bucket, an index. Drawn as an open-ended rectangle.
Data flow. An arrow. Labelled with the data: signed access token, enriched product record. Never with a verb.

Three connection rules make a DFD honest, and breaking them is what produces diagrams that look plausible and mean nothing:

Every flow touches at least one process. An entity cannot write straight to a store, and one store cannot flow into another. If data moves between two stores, something is moving it — name that process.
Every process has an input and an output. A process with input and no output is a black hole; output with no input is a miracle. Both are real defects, and the diagram is how you find them.
Label flows with nouns. "Order submitted" is an event; "order payload" is data. A DFD carries the second.

Levelling

DFDs are drawn at levels. A context diagram (level 0) shows the whole system as one process with its external entities around it — often the most useful single page you will produce. Level 1 opens that process into its major sub-processes. Deeper levels open one sub-process each.

The rule that keeps levels coherent is balancing: the flows crossing the boundary of a level-1 diagram must match the flows on its parent exactly. A flow that appears from nowhere on the detailed diagram means the parent is wrong.

How to create a data flow diagram, step by step

Draw the boundary. What is inside the system you are describing, and what is outside it.
Place the external entities. Everyone who sends data in or receives it out. Keep them on the edges.
Draw the context diagram first. One process in the middle, entities around it, labelled flows between. Get agreement here before opening anything up.
Decompose into major processes. Four to seven is a good level-1 diagram. More than that and you are already at level 2.
Add the data stores. Place each next to the processes that read and write it.
Connect everything with labelled flows. Nouns only. Check each process has both an input and an output.
Balance against the parent. Every flow crossing the boundary should appear on the level above, with the same name.

Worked examples you can open and edit

Editable diagrams — open one and follow a single arrow end to end.

Data flowNarratedWatch onlySign in with Google, explainedSign in with Google as a data flow — which system holds what, and what crosses between them.View example Play presentation
Data flowProduct catalog and PIM pipelineRaw supplier data becoming channel-ready listings: ingest, enrich, validate, syndicate.View example Use template
Data flowPersonalization and recommendationsBehaviour in, ranked shelf out — events, features, scoring and the store that holds each.View example Use template
Data flowNarratedWatch onlyHow passwords are stored safelyA small, complete flow where the data store is the whole point of the diagram.View example Play presentation
Data flowNarratedWatch onlyWhat happens when you open a websiteOne page load traced hop by hop, from name lookup to rendered bytes.View example Play presentation
Data flowReading a value-stream mapMaterial and information flow side by side — the manufacturing cousin of a DFD.View example Use template

Where data actually lives: signing in with Google

The OAuth example is the one to read if you only read one, because it makes visible the thing people get wrong about federated login: your application never receives the password. The external entity holds the credential, the identity provider transforms it into a token, and what crosses into your system is that token and a profile — nothing more. Drawn as a data flow, the boundary does the explaining. Written in prose, it takes three paragraphs and people still ask whether you store the password.

A pipeline: supplier data becoming a product listing

The product catalogue example is a straightforward four-stage pipeline — ingest, enrich, validate, syndicate — and it shows why data stores belong on the diagram. The raw feed, the enriched master record and the channel-ready listing are three different stores holding three different shapes of the same product. A diagram with only processes would suggest data flows straight through; showing the stores makes it obvious where you can restart, audit or roll back.

Building one in Diagramium

Open the data flow diagram editor.

Drop the four element types from the shapes panel — external entity, process, data store, plus a container for a trust boundary.
Drag from a port to draw a flow between two elements.
Label every flow in the inspector with the data that travels. The label sits in a pill that masks the line behind it, so a dense diagram stays readable.
Group with a boundary to show which elements are inside your system.
Press Present to trace one flow at a time — which is how a data-protection review should be walked through.

The data flow editor is canvas-based; there is no text syntax, and the Text editor tab is hidden in this mode.

Present reveals the diagram element by element, so a reviewer follows one path instead of scanning a finished page.
Export PNG, SVG or PDF free without an account — PDF is convenient when the diagram is an appendix to an assessment. Animated SVG, GIF and video need a free account, not a subscription.
Embed a published diagram as an interactive player in internal documentation.

Common mistakes

Flows labelled with verbs. "Sends order" is an action. "Order payload" is data. Only the second belongs on a DFD.
Store-to-store arrows. Data does not move itself. Insert the process that moves it, and name it.
Treating it as a flowchart. No decisions, no diamonds, no sequence. If you find yourself wanting a diamond, you want a different diagram.
Unbalanced levels. A flow on the detail diagram that does not exist on its parent means one of the two is wrong.
Processes with one side missing. Input with no output, or output with no input, is either a modelling error or a genuine gap in the system.
Too much on one level. Past about seven processes, decompose. A DFD's readability collapses faster than a flowchart's.

For which components exist and how they are deployed, draw a system architecture diagram.
For the order in which those components talk, use a sequence diagram.
For the structure of the data once it is stored, draw an ER diagram.
For control flow and decisions, use a flowchart.
To reason about who might attack each flow, build a STRIDE threat model — it is a data flow diagram with trust boundaries and threats attached.

Questions people actually ask

What is the difference between a data flow diagram and a flowchart?

A flowchart shows control flow: what happens next, and which branch is taken. A DFD shows data movement and has no notion of order or decisions at all. The two answer different questions about the same system.

What are the four elements of a DFD?

External entity, process, data store and data flow. Everything on a correct DFD is one of those four.

What is a context diagram?

Level 0: the entire system drawn as a single process, surrounded by its external entities, with the flows between them labelled. It is usually the most valuable page in the set because it fixes the system's boundary.

Can a data store connect directly to an external entity?

No. Every flow must touch at least one process. If it looks like a store talks straight to an outside party, there is an unnamed process doing it — and naming it is often the finding.

How many levels should I draw?

As many as the question needs, and rarely more than two. A context diagram plus one level of decomposition covers most reviews; go deeper only for the sub-process actually under discussion.

Ready to build one? Open the Data flow editor on a blank canvas, or start from one of the templates above — they are all editable.Open the Data flow editor Browse all templates