A data flow diagram generator built from flowchart shapes

A data flow diagram generator, in Mermaid, is a flowchart with a dress code. Mermaid has no DFD type and no dfd keyword. You draw level 0 and level 1 with flowchart shapes: a parallelogram for an external entity, written customer[/Customer/], a rectangle for a process, and a cylinder for a store, written orders[(Orders)]. The arrows are data moving, not the order of a user's clicks. If you needed the clicks, you wanted a different picture. This page is the data.

I generate these by hand or from a sentence, then I correct the shapes, because a model will happily emit a decision diamond and call it a data flow. A diamond asks a question. A DFD does not ask. It shows what enters a process and what leaves, and where a store sits between them. The flowchart syntax reference is still the grammar. The discipline is which shapes you allow yourself to use.

Level 0 is the system and the outside

Level 0, sometimes called a context diagram, is one process and the parties outside it. The process is a single rectangle named for the system. External entities are parallelograms. Arrows between them are named data flows. I leave data stores off level 0. The point of this picture is the boundary: what the world sends in, and what the system sends back. Stores are inside the boundary, and level 1 is where they appear.

Here is an order desk at that altitude. The customer, the warehouse, and the card network are outside. "Order system" is the only process.

flowchart LR
  customer[/Customer/] -->|Order| system[Order system]
  system -->|Receipt| customer
  warehouse[/Warehouse/] -->|Stock status| system
  system -->|Pick list| warehouse
  network[/Card network/] -->|Auth result| system
  system -->|Charge| network

Read the arrows as nouns. An order moves from the customer into the system. A receipt moves back. A pick list moves to the warehouse. If you catch yourself labeling an arrow "then," you are drawing a flowchart of steps and using DFD shapes as decoration. Rename the arrow to the data, or switch tools and draw the steps honestly.

One process is the rule I break first when I am excited about a design. Two rectangles at level 0 means I have started level 1 without admitting it. Collapse them until the outside world is the interesting part. The inside gets its own figure, directly underneath, so a reader can zoom in without pretending the context diagram was a full design.

Ids stay words. customer, system, warehouse, network. The labels carry the spaces and the capitals. I do not use 1.0 as an id. A leading number is a common way to ask the parser for a bad time, and the Gane-Sarson habit of numbering processes can wait in the label, quoted, if you truly need the number. Most teams need the name more than they need 1.0.

Level 1 opens that one process

Level 1 replaces the single rectangle with the few processes that actually transform the data, and it adds the stores those processes read and write. External entities remain parallelograms. They should be the same parties as level 0. A new external that appears only at level 1 means the context diagram was incomplete. Go back and add them, or admit the new party is internal and draw a process instead.

Processes are rectangles: take the order, check stock, charge the card. Stores are cylinders: orders, inventory, card receipts. An arrow into a cylinder is a write. An arrow out is a read. I say that in the prose because the arrowhead alone will not teach a new teammate your convention, and I keep the convention stable across the page.

flowchart LR
  customer[/Customer/] -->|Order| take[Take the order]
  customer -->|Payment| bill[Charge the card]
  take -->|Order row| orders[(Orders)]
  take -->|Item check| stock[Check stock]
  stock -->|Count query| inventory[(Inventory)]
  inventory -->|Count| stock
  stock -->|Reserved line| orders
  bill -->|Charge request| cards[(Card receipts)]
  bill -->|Receipt| customer
  orders -->|Total| bill

This is still a sketch of an order desk, not a schema. The cylinder orders is a store in the DFD sense, a place data rests. It might be one table, or three, or a queue plus a table. The entity relationship diagram is where the tables go. The ERD diagram creator note is that next picture, and mixing the two in one figure is how a foreign key gets read as a data flow. If the arrow means "this row points at that row," it does not belong here. If the arrow means "a total moves from the order store into the charge process," it does.

I kept the customer as one parallelogram with two outgoing flows. That is legal and readable. Duplicating the customer on both sides of a huge chart is a paper technique for shortening arrows. Mermaid will not automatically duplicate a node for you. If the chart becomes a plate of spaghetti, split level 1 by process group instead of cloning entities. "Take the order" and "charge the card" can be two figures when one figure turns into a knot. Level 1 is allowed to be a set of diagrams. It is not a contest to fit the company on one screen.

Gane-Sarson and Yourdon, without the folklore

Two textbook styles exist, and teams argue about them as if the argument shipped software. Gane-Sarson draws a process as a rounded rectangle, a store as an open-ended rectangle, and an external entity as a square. Processes often carry a number such as 1.0 in the corner. Yourdon and DeMarco draw a process as a circle, a store as a pair of parallel lines, and an external as a box. The arrows in both styles are data flows. The shapes are the dialect.

Mermaid gives you neither dialect as a diagram type. Circles, open rectangles, and the little number tab are not a mode you can switch on. The approximation on this page is deliberate and limited: parallelograms for externals, rectangles for processes, cylinders for stores. A rectangle is closer to Gane-Sarson than a circle would be, and a cylinder is closer to "a database icon" than to either textbook's store. I would rather be plain about that than pretend [(Orders)] is a standard Yourdon symbol. It is a Mermaid cylinder we are agreeing to read as a store.

If your organization has a written standard that demands circles, say so in the paragraph and keep the Mermaid file as the editable source of the flows. The standard can have the pretty export. The flows, the names, and the levels are the part worth diffing. I have watched a review reject a correct level 1 because the process was not a circle. The data was right. The silhouette was "wrong." Fix the silhouette in the tool that cares, or change the standard to accept an explicit legend. A legend of one line is enough: parallelogram outside, rectangle process, cylinder store.

Numbers are optional. If you want them, put them in the quoted label, take["1 Take the order"], and keep the id as take. Do not write a node as 1.0[Take the order] or as an id that starts with a digit. That form is how a file that looked like a textbook figure becomes a parse error. The guide to creating a flowchart in Mermaid shows how ids and labels differ. The same split saves DFD files. The number is a label. The handle is a word.

What a generator gets wrong

I will paste a sentence into the AI flowchart generator when I want a first pile of nodes. "Level 0 of an order system, customer, warehouse, and card network around one process" is a fair prompt. The result is a draft of syntax. It is not a DFD until the shapes match the roles. The usual misses:

• A diamond for "payment ok?" which is control flow, not a data flow.
• A store drawn as a rectangle, so it looks like a process that happens to be named Orders.
• An external drawn as a person-shaped stadium, which Mermaid will render and a DFD reader will misread as a start node.
• An arrow labeled "then validates," which is a step sneaking back in.
• A process id of 1 or 2.0 that fails the parser, or a node named end that will close a subgraph the moment you add one.

Free accounts get 5 AI uses in total, and the panel can edit or fix a diagram you already pasted. Spend an edit on "change Orders to a cylinder and Customer to a parallelogram" rather than on a new poem. Then look at the picture yourself. The generator does not know that level 0 should hide stores. You do, and you delete the cylinders from that figure.

The editor is where that cleanup is pleasant. It is free without an account, and the preview is live, so swapping [Orders] for [(Orders)] shows the cylinder immediately. Parentheses in a label need quotes. A store named with a note becomes orders["Orders (hot)"] if you insist on the parentheses. I usually refuse the parentheses and put the note under the figure. Quoted shapes are easy to mistype, and a DFD already has enough brackets.

Keep the levels honest as the system grows

A new microservice is not automatically a new external. If your team operates it, it is inside the boundary and it wants to be a process or a store at level 1. An external is someone else's system or a person outside the system you are describing. I have drawn our own billing service as a parallelogram to avoid redrawing level 1. The context diagram then claimed we do not own billing. Finance disagreed, correctly.

Balancing is the textbook word for a check I still do. Every flow between an external and the system at level 0 should show up at level 1, touching some process. If level 0 sends a receipt to the customer and level 1 never does, one of the figures is stale. I do this with a list, not with faith. Write the level 0 arrow labels in a column, and tick them off against level 1. The ones without a tick are the design discussion. The ones that appear only at level 1 are either an internal flow, which is fine, or a missing external on the context diagram, which is a fix.

Stores need a writer and a reader, or you should say why not. A cylinder with only an incoming arrow is a log. That can be real. A cylinder with no arrows is a decoration. Delete it. A process with only outgoing arrows is a miracle that creates data from nothing. Sometimes the source is a clock or a file you forgot to draw. Draw the source, or accept that the process is underspecified and mark it in the prose.

The what a flowchart is used for post is the decision-and-policy cousin of this page. Checkout as a flowchart asks "card accepted?" Checkout as a DFD asks which data moves when a charge happens. You might want both files. They answer different review comments. The flow charts note and the schematic diagram creator note cover still other shapes. A schematic of boxes and wires is not a data flow unless you apply the same rules: named data, processes, stores, externals, levels. The words on the arrow are the test. "HTTPS" is a technology. "Auth result" is a flow. I know which one I can discuss with a product manager.

Templates and the legend you should paste

The template library has flowcharts you can cannibalize for layout ideas. None of them is a DFD until you swap the shapes and rewrite the verbs as nouns. Starting from a login flowchart and relabeling the diamonds will produce a haunted diagram, questions wearing store-shaped hats. Start from the two figures on this page instead. Replace Customer with your actor, Order system with your system name, and the cylinders with the stores you actually keep.

Paste a one-line legend under the first figure in any doc that leaves your team: "Parallelograms are outside, rectangles are processes, cylinders are stores, arrows are data." That line prevents a well-meaning edit from introducing a diamond next sprint. I have seen the diamond return within a week because someone used the file as a generic drawing surface. The legend is a fence. It is also a hint to the next generator prompt: do not add a decision node.

Direction is a reading choice. Left to right matches the way I read a flow between parties. Top to bottom works when you have a tall stack of stores and a narrow wiki column. Pick one per figure and keep level 0 and level 1 on the same direction so the eye does not relearn the page. Subgraphs are optional. A subgraph titled "Inside the order system" around the level 1 processes can help, and it introduces end as a closer. Your node ids must not be end. I skip the subgraph until the figure is so wide that the boundary is unclear. Level 0 already is the boundary.

Generate the shapes, then check the nouns

Write the level 0 sentence in one line, generate or type the single process and the externals, and name every arrow with the data. Open level 1 only after those names feel complete. Then explode the process, add cylinders for the resting data, and tick the flows off the list. Fix any id that starts with a number. Remove any diamond that snuck in.

Open the editor with the level 0 figure and rename it to your system before you add a single store. When the boundary is right, duplicate the idea into a level 1 file and keep them side by side in the doc. A generator will speed the first draft and will not balance the levels for you. That check is the work. The shapes are just how Mermaid lets you do a DFD without a DFD keyword.