Basic process flowchart template
A basic process flowchart template running from request to closed: one start, four labelled decisions, a rework loop capped at the second failure, and three separate endings. The smallest complete flow you can copy and rename.
How it works
Rename the five phases to your own stages
Request, Review, Do the work, Check and Close are placeholders for intake, triage, execution, verification and closure. Replace them with the stage names your team already says out loud. If you have no verification stage at all, merge Check into Do the work rather than leaving an empty column that implies a review nobody performs.
Name the three roles, and keep the reviewer separate
Rename Requester, Process owner and Reviewer to your real roles — one lane per decision-maker, not per person. The one merge to resist is putting the reviewer and the person doing the work in the same lane. If they are the same individual, the check step is decoration, and you should say so on the chart instead of drawing a review that never fails.
Write your minimum request fields into row two
"Describe the need and the deadline" is deliberately vague because your fields are not ours. List them explicitly: what is wanted, why, the date it is needed by, who to come back to. That same list is what "Enough information to start?" tests against two rows later, so write it once in the comment field and reuse it in both places.
Set your own rework cap
The review decision escalates on the second failure. If your process genuinely allows three attempts before escalation, add a branch and say so; if it allows none, delete the return arrow to "Complete the work" and send every failure straight to escalation. What matters is that the loop has a stated exit, because an uncapped one is how work disappears for a quarter.
Decide who the escalation reaches, and what they may do
"Change the approach or close the request?" assumes somebody is allowed to close a request unresolved. If nobody in your organisation can, delete "Closed without meeting the criteria" and make the escalation always return to "Agree the acceptance criteria" — then be honest that the process has no way to stop, and name who carries that risk.
Use only the shapes you actually need
This chart uses six kinds of box and no more: a start, plain process steps, decisions, one record step, and two kinds of terminator between them covering its three endings. That is deliberate. Microsoft's guidance for its own Basic Flowchart template says any shape can carry whatever meaning is agreed on by the people who will create and read the flowcharts, and that most flowcharts tend to use only three or four of the shapes. Agree a small set, write down what each one means, and stop there.
Frequently asked questions
What are the stages of a basic process flowchart?
Five, in the general case. Intake, where the work is requested and described. Review, where somebody decides whether the request is complete enough to act on. Execution, where the work is done and recorded. Verification, where a second person tests the result against criteria agreed beforehand. Closure, where the outcome is confirmed and the request is formally shut. The chart above uses exactly those five as its phase columns — Request, Review, Do the work, Check and Close — because almost any operational process, from a maintenance job to a document change, fits that spine once you stop naming the stages after the department that owns them.
Who owns a process drawn like this?
Three roles, with three different things to own. The requester owns the information: if the request is incomplete, the process cannot start, and the chart returns it rather than guessing. The process owner owns the flow itself — the queue, the assignment, the due date, and the escalation when review fails twice. The reviewer owns the criteria and applies them, which is why the criteria are agreed in the reviewer's lane before the work begins rather than invented at the check step. Give the process owner the end-to-end accountability. Without a named one, a request that stalls between two lanes belongs to nobody, which is the most common way work is lost.
What should happen when work fails the review twice?
It should stop going round. The first failure is ordinary: the reviewer lists the specific gaps and the work returns to be redone. A second failure on the same request means something other than effort is wrong — the criteria were unclear, the approach cannot meet them, or the request itself was not achievable. Sending it round a third time repeats the same result more slowly. In this chart the second failure escalates to the process owner, who chooses between changing the approach, which returns to the point where acceptance criteria are agreed, and closing the request unresolved. Both outcomes are recorded. Neither leaves the work in limbo.
Do flowchart shapes have standard meanings?
Less than most people assume. There are widespread conventions — a rounded box for a start or end, a rectangle for a step, a diamond for a decision — and following them makes a chart easier for a stranger to read. But Microsoft's own documentation for its Basic Flowchart template states plainly that any shape can carry whatever meaning is agreed on by the people who will create and read the flowcharts, and notes that most flowcharts tend to use only three or four of the shapes. So there is no shape library to learn before you can start. Pick a handful, define them in a legend, and be consistent. Clarity comes from labelling the decision exits, not from the geometry.