What do the different symbols in a process flow diagram mean

TL;DR: Most symbol guides hand you a glossary and stop there. This one shows IT company owners what each process flow diagram symbol actually represents in a live business process, from decision gates to handoffs to dead ends, and how that logic maps directly to automation triggers. Read on to turn a static diagram into a working workflow.

What process flow diagram symbols are and why they matter

Process flow diagrams use a shared visual language built on standardized shapes. Each symbol carries a specific meaning, and that meaning is consistent because the core set follows the ISO 5807 standard (published 1985, still the reference most documentation teams use). When everyone reads the same shape the same way, a diagram becomes a communication tool rather than a personal sketch.

The problem with skipping standardization is concrete: a rectangle used where a diamond belongs tells a reader there is no decision point, so they follow a linear path through logic that actually branches. That misread creates rework, missed approvals, or broken handoffs.

The stakes rise further when a business process flow diagram feeds into automation. Tools that parse flowcharts to generate workflows, trigger conditions, or routing rules depend on symbol type to distinguish an action from a decision from a data input. Use the wrong shape and the automation either fails silently or routes incorrectly.

Most teams underestimate this. They treat the symbol set as decoration rather than instruction. If you are building a process flow for your business, getting the symbols right from the start is the difference between a diagram that documents and one that actually drives work.

The six core symbols and what each one means

The six process flow diagram symbols come from a shared notation standard — ISO 5807, published in 1985 and still the reference most diagramming tools default to. Each shape carries a fixed meaning. Use the wrong one and anyone reading or automating your process later has to guess at your intent.

Here is what each symbol means and where it shows up in practice.

Oval (terminator): Marks the start or end of a process. Every diagram has exactly two: one labeled "Start," one labeled "End." In an IT onboarding workflow, the oval at the top might read "New hire request submitted."

Rectangle (process step): The most common shape in any diagram. It represents a single action or task performed by a person, system, or both. "Provision user account in Active Directory" is a rectangle. Most of the boxes in your diagram will be rectangles.

Diamond (decision): A branching point where the flow splits based on a yes/no or true/false condition. "Does the user have admin rights?" routes to two different paths. Diamonds are where business process modeling gets complex fast — nested diamonds are usually a sign the process needs simplification before it gets documented.

Parallelogram (input/output): Represents data entering or leaving the process. A form submission is input; a generated report is output. This shape is the one most teams skip or replace with a rectangle, which is exactly the ambiguity that breaks automation later. When you build and automate a business process workflow, the parallelogram tells the automation engine what data it is receiving or producing at that step.

Arrow (flow line): Shows direction and sequence. Arrows connect every other shape and define the order of execution. A missing or ambiguous arrow is the single fastest way to make a diagram unreadable.

Cylinder (database/storage): Represents stored data, typically a database or file system. "Log ticket in ServiceNow" or "Write to client record in CRM" would use a cylinder. Teams building integrations need this shape to be explicit — it signals a read or write operation to a system, which matters when you use a visual workflow builder to map automation triggers.

The table below shows each symbol at a glance:

Getting these six right is the baseline for any diagram that other people — or automation tools — need to act on. If you want to identify which processes are ready for automation, a correctly notated diagram is where that assessment starts.

What the oval symbol means in a process flow diagram

The oval is the terminator symbol. It marks where a process starts and where it ends — nothing more, nothing less.

Every valid process flow diagram needs exactly two ovals: one labeled "Start" and one labeled "End." If you see a diagram with only one, the process is incomplete. If you see three or more, someone has added unnecessary branches that should be decision points (diamonds) instead.

In practice, the start oval might read "Customer submits request" and the end oval "Invoice sent." Everything between those two points is the process. That boundary is what makes the diagram readable to someone who didn't build it.

This matters operationally. When you move from business process modeling into automation, the terminator ovals define the trigger and the exit condition for any automated workflow. Without clear start and end points, automation tools have no reliable scope to work within, and you end up with processes that run indefinitely or stop at the wrong step.

How to use these symbols when building a process flow diagram

Start with the oval. Place one at the top of your canvas labeled "Start" and one at the bottom labeled "End." Every other symbol sits between those two points. Without them, readers have no anchor and the diagram fails its basic job.

From the start oval, draw your first process step using a rectangle. Label it with a verb and an object: "Submit request," not "Request." Verb-first labels make the action unambiguous, which matters when you hand the diagram to someone who wasn't in the room when you built it.

When a step requires a decision, switch to a diamond. Write the condition as a yes/no question inside it, then draw two arrows out, each labeled "Yes" or "No." This is where most business process flow diagrams break down. Teams use a rectangle for a decision because it "looks cleaner," but that removes the branching signal entirely. Anyone reading the diagram later has no way to know a choice was made.

Follow this sequence when placing your process mapping symbols:

1. Drop the start terminator and name it.

2. Add each process step as a rectangle, one action per shape.

3. Insert a diamond wherever the path splits based on a condition.

4. Label every arrow with the outcome it represents (Yes, No, Approved, Rejected).

5. Connect all paths back to the flow or to the end terminator. No arrow should dead-end mid-diagram.

6. Place the end terminator. Confirm every path reaches it.

Keep each rectangle to one action. If a step needs two sentences to describe, it is probably two steps. That discipline is also what makes a diagram automation-ready. When you later build and automate a business process workflow, tools need discrete, single-action steps to map triggers and outcomes cleanly.

Once the diagram is complete, walk it from Start to End out loud. If you have to explain a symbol to do it, the label is wrong. Fix the label, not the audience.

Common symbol mistakes that make diagrams hard to read

Three errors show up in process flow diagrams more than any others, and each one creates a different kind of confusion for anyone trying to follow or automate the process.

Using rectangles where diamonds belong is the most common. When a step has two possible outcomes — approve or reject, pass or fail — it needs a diamond. Drawing it as a rectangle hides the branch entirely. Anyone reading the diagram assumes the process moves in one direction, which breaks down the moment a real decision has to be made.

Skipping terminators is the second. Diagrams that start mid-flow or trail off without a clear endpoint force readers to guess where the process begins and where it stops. That ambiguity compounds when you're trying to build and automate a business process workflow, because automation tools need explicit start and end triggers.

Drawing arrows that loop without a decision gate is the third. A loop back to an earlier step is valid — for retry logic, for example — but only when a diamond controls the re-entry condition. Without it, the diagram implies an infinite loop with no exit, which is a logic error, not just a visual one.

Before sharing any diagram, audit it for these three: every branch has a diamond, every path has a terminator, and every loop passes through a decision gate. Correct workflow diagram symbols are what separate a diagram someone can act on from one they have to decode.

How a correctly drawn diagram maps to an automated workflow

A well-drawn process flow diagram is essentially a specification document for automation. Each symbol type maps directly to a logic element a workflow tool needs to execute.

Rectangles (process steps) become tasks or actions in your automation engine — "send invoice," "assign ticket," "notify manager." One rectangle, one discrete action.

Diamonds (decision points) become conditional branches. If the condition is true, the workflow takes one path; if false, it takes another. This is where most business process flow diagrams break down in practice: a diamond with only one exit arrow means your automation has no fallback, and the workflow stalls silently.

Arrows become triggers and sequencing rules. The direction and connection point matter. An arrow from a diamond's "No" exit that loops back without passing through another decision gate creates an infinite loop in automation — the same error that makes process mapping symbols ambiguous on paper makes them dangerous in production.

Terminators mark where the automation starts and stops. Skip them in your diagram, and your automation tool has no defined entry point.

Understanding what workflow mapping is actually for makes this translation clearer: the diagram isn't documentation after the fact, it's the build spec.

Revo reads that spec directly. Each workflow diagram symbol you draw corresponds to a no-code logic block in Revo — no translation layer, no developer required. Draw it correctly, and the automation runs.

Closing

Getting your process flow diagram symbols right isn't just about making it look professional — it's about making it actionable. When you use the standard six shapes correctly, your diagram becomes a blueprint that automation tools can read and execute without translation or guesswork. A rectangle means action, a diamond means decision, a parallelogram means data moves — that consistency is what turns a static diagram into a running workflow.

Once your diagram is mapped with standard symbols, the logic is already there. The next step is moving it into a visual workflow builder where that diagram becomes a live, automated process without writing a single line of code. Ready to turn your mapped process into automation? Start by exploring how Revo's visual workflow builder converts correctly-notated diagrams into executable workflows.

FAQ