Basic Flowchart Template
A standard framework for mapping out processes, decision trees, and system workflows clearly and consistently.
In this resource
§1 Overview
A well-structured flowchart brings shared clarity to complex operational sequences, ensuring that an entire project team understands task dependencies and routing logic.
The KEVOS® Basic Flowchart Template standardises how processes are visualised across project documentation. By restricting the diagram to a fundamental set of universally recognised shapes, we prevent misinterpretation and make the logic accessible to both technical and non-technical stakeholders.
Contents§2 Standard Symbols
To maintain visual consistency across all project processes, this template utilises a strict four-symbol vocabulary. Do not invent custom shapes for internal business processes.
| Symbol Shape | Designation | Application Rule |
|---|---|---|
| Oval (Pill) | Start / End | Indicates the definitive beginning or conclusion of a process map. Every flowchart must have at least one of each. |
| Rectangle | Process | Represents a specific action, task, or operation performed by a human or system. |
| Diamond | Decision | Indicates a branching point where the flow diverges. Every branch leaving a diamond must be labelled (e.g., Yes / No). |
| Parallelogram | Input / Output (I/O) | Shows data entering the process or a material/informational output being generated. |
§3 Worked Example: Defect Handling Workflow
To illustrate the practical application of the blank template, we review a defect handling lifecycle mapped for Mary's Consulting - New Company Website.
This process begins immediately upon a defect being discovered. The workflow relies on clear decision gates to determine task priority and routing:
- Initial Logging: The process begins when a defect is found. It is immediately logged in Jira, capturing the severity, functional area, and reproduction steps.
- Triage Decision: The flow reaches a diamond node asking: Severity 1 or 2?
- Yes path: The issue is assigned immediately, and affected work is blocked.
- No path: (Severity 3 or 4) The defect is assigned to the subsequent sprint without immediately blocking the active development pipeline.
- Resolution: Both triage paths eventually converge on the developer fixing the defect on a dedicated feature branch, followed by code review and automated testing.
- Verification Decision: A final diamond asks: Verified by tester?
- No path: The defect is not reopened; it routes back to the developer to continue fixing.
- Yes path: The defect is closed, reaching the end node of the flowchart.
Note on annotations: As demonstrated in the example above, complex logic that does not fit neatly inside a standard shape (such as defining what happens on a 'No' path during triage) should be handled using a brief external note appended to the flowchart.
§4 Application Guidelines
Single Directionality
Ensure the primary flow of logic travels either top-to-bottom or left-to-right. Avoid tangled crossing lines which confuse the operational sequence.
Closed Loops
Every decision diamond must have its branches cleanly resolved. Do not leave 'No' paths floating; they must route to an end state or loop back to an earlier process.
Consistent Granularity
Maintain a uniform level of detail throughout the map. Do not mix high-level departmental phases with micro-level software clicks in the same diagram.