Process map vs flowchart. The terms get used interchangeably, and they should not be.

The short answer. One is a notation, the other is a category.

Ask five people in a business meeting to draw "a flowchart" and a "process map" and most will draw the same thing: boxes, a diamond for a decision, arrows connecting them. That overlap is exactly why the terms get used interchangeably, and why it matters when they should not be. A flowchart is a specific notation, a defined set of shapes showing a sequence of steps and decisions from start to finish. A process map is the broader umbrella term for any diagram documenting how a process actually runs, and a basic flowchart happens to be the simplest, most familiar member of that broader family. Every flowchart is a process map. Not every process map is a flowchart.

This distinction is not the same question as our guide to the types of process maps, which sets out the fuller family, flowchart, swimlane, SIPOC, value stream map and BPMN, and which question each one answers. This piece answers a narrower thing first: why the word "flowchart" specifically keeps getting used as if it meant the whole category, and when reaching for it instead of the broader term actually costs you something.

How they differ. Scope, formality, and where the words actually come from.

The practical difference is scope. A flowchart answers one question: what happens, and in what order. It assumes a single owner or a single system carrying the work from trigger to outcome, and it says nothing about who is responsible for each step, what systems are touched, or how long anything takes. A process map, in its fuller forms, can answer all of those at once: a swimlane version adds ownership, a value stream map adds timing, a SIPOC adds boundaries and stakeholders. The word "process map" gets used loosely to mean either the specific narrow diagram or the whole family, which is where most of the confusion starts.

The history of the two terms points the same way. Industrial engineer Frank Gilbreth, working with his wife Lillian Gilbreth, introduced the flow process chart in a paper presented to the American Society of Mechanical Engineers in 1921, aimed specifically at documenting manufacturing steps in sequence. The symbol set that most people now picture when they hear "flowchart" was formalised decades later for computing use, first in ANSI's X3.5 standard in 1963 and then internationally in ISO 5807 in 1985. "Process mapping" as a broader discipline came later still, absorbing the flowchart as its simplest notation and adding swimlanes, SIPOC and value stream formats as the questions businesses needed to answer got more specific than plain sequence.

Which to use and when. Match the word to the question, not the drawing.

Call it a flowchart when the process genuinely has one owner, or moves through a single system, and the only useful question is what comes next. A simple approval step, a single automated workflow, a decision tree for a support agent to follow: all of these are flowcharts, and calling them anything grander does not add information.

Reach for the wider term, and the wider set of formats behind it, the moment the process crosses more than one person or department and the handoffs matter as much as the steps. If the real question is "who keeps dropping this between marketing and sales", a plain flowchart with no roles on it cannot answer that, no matter how carefully it is drawn. That is a swimlane process map's job, and our guide to how to create a process map covers the method for building one properly, whichever format the underlying question turns out to need.

How Lauren would decide. Start from the decision, not the label.

When a client asks me for "a flowchart" of something, the first thing I do is ignore the word and ask what decision the diagram needs to support. A client once asked for exactly that, a flowchart of their client-onboarding process, because that was the term they knew. Five minutes into the conversation it was clear the actual problem was a handoff: onboarding tasks were dropping between the sales team and delivery team, and nobody could say whose job it was to catch them. A flowchart, correctly drawn, would have shown the steps and told them nothing new. What they needed, and what we built instead, was a swimlane process map with sales and delivery as separate lanes, which made the gap visible in the first five minutes of looking at it rather than after another quarter of dropped handoffs.

My rule: never let the label someone asks for decide the format. Ask what decision the diagram needs to support first, choose the notation that actually answers it, and then call the finished artefact whatever the client is comfortable calling it. Getting the terminology exactly right matters far less than getting the right shape of answer onto paper, and a business that insists on "just a simple flowchart" for a genuinely cross-functional problem usually ends up redrawing it as something else within a month anyway.

If you already know you need the fuller family of formats and want to see how they compare side by side, our guide to the types of process maps is the next read. If you want the shape vocabulary itself, from decision diamonds to terminator ovals, our reference on process map symbols covers the dozen shapes actually worth knowing.