A data flow diagram follows information through a system. Its main elements are external entities, processes, data stores and directed flows. Unlike a flowchart, it does not use arrow position to describe the order in which a person performs tasks.
Name the information on each arrow
Use labels such as “shipping details,” “validated order” and “payment confirmation.” A verb like “submit” may describe an action, but it does not tell a reader which data crosses the boundary. Name processes with verbs that explain their transformation, such as “Validate order.”
Keep external entities separate from internal data stores. The customer is a source or destination; the order store persists information for other processes.
Move from context to detail
Begin with the system as one process and identify its outside sources and destinations. Expand only the area under review, preserving the same external inputs and outputs. If a new flow appears in a detailed view, explain whether the overview omitted it or the system design changed.
Avoid showing a direct flow between two stores without a process that explains the transfer. Use an ER diagram to describe relationships between stored entities instead.
Audit the boundaries
Check that sensitive fields are named only when needed and that every destination is intentional. A generated diagram does not verify access permissions or retention settings. Use it to ask concrete review questions: who provides this field, which process changes it and what store holds the result?
For deployment and service dependencies, switch to an architecture diagram.
Make it about your work
Edit this starting prompt, then send it when you are ready.