How to create a flowchart from a document
How to turn a document whose steps were never numbered into a flowchart: which passages are not steps at all, where scope, definitions and responsibilities belong instead, and why the chart comes out too long.
Building a flowchart from a document means separating the passages that describe an action from the three kinds that never do (scope, definitions and responsibilities) and drawing only the first.
The short version
- Most of a document describes no action: scope, definitions and responsibilities are not steps.
- Charts drawn from documents run twice as long as the process, and the excess is prose.
- Every passage that is not a step still has a home: a route, a branch label, a lane or a comment.
- A defined term is usually the criterion its decision was missing: mine the definitions, do not draw them.
- One sentence naming three cases is one diamond with three exits, not three steps.
Scope, definitions and responsibilities are not steps
A document is written to be read, not performed, and only a minority of it describes anybody doing anything. Section one states scope, section two defines terms, section three lists who is responsible for what, and the actions start somewhere on page four. Transcribe that structure and the result is a diagram twice the length of the process, in which a dozen real steps sit among a dozen boxes nobody performs.
Sort every passage into action, condition or neither before typing anything. Actions become boxes and conditions become labelled decisions; that conditional hunt is nearly the whole job when the source is a numbered SOP, and it has its own guide. What is particular to a document is the third pile, and the mistake is treating it as waste. Scope, definitions, responsibilities and references each have a destination that is not a box.
The example below is a management of change policy for an operating site, rebuilt as 26 rows across six phases from "Request" to "Implementation and close-out". Watch where its non-steps went. The exclusion in its scope paragraph is now "Replacement in kind?", with an "In kind" exit that leaves the process; its risk definitions are now the branch labels on "What level of hazard review?"; its table of authorities is a lane. Four arrows point back up the sheet; the longest re-enters the technical review.
Six phases, one policy document
A management of change policy, rebuilt: watch its scope paragraph arrive as a route out, its risk definitions as branch labels and its authorities as a lane.
Scope becomes a route out
The policy's scope paragraph excludes replacements in kind. That exclusion is neither a box nor a footnote: drawn, it is "Replacement in kind?" with an "In kind" exit to "Handled as maintenance work", reached two rows after "Change proposed" and before any work is committed.
One sentence, three exits
A single clause classified changes by type, and it is one diamond rather than three steps: "Permanent, temporary or emergency?", where "Temporary" collects "Set the expiry date and removal plan" and "Permanent" goes straight to the technical basis. The emergency exit was printed in a later section.
Definitions are the criteria
The document buries its risk definitions in a section nobody would draw; they are the exits of "What level of hazard review?": "Low risk", "Medium risk" and "High risk". A definition is what makes a branch decidable, and all three routes converge on "Assess impact on safety systems and limits".
The responsibilities list is the lanes
Which level of authority is required was a table in the document; here it is the "Authorising manager" lane, attached to the row where it decides something. "Authorised at the required level?" stops on "Refused", proceeds on "Authorised", and returns on "More work needed" to the technical basis.
The longest arrow points back
"Pre-startup safety review passed?" sends outstanding actions round again before start-up. Later, "Still needed at the expiry date?" offers "Convert to permanent", which re-enters "Document the technical basis": the longest arrow here, and the clause a temporary change survives on.
How it works
Sort every passage into three piles
Read the document once, marking each passage action, condition or neither. "The originator shall log the change" is an action. "For changes other than replacement in kind" is a condition. Scope, definitions, the responsibilities table and the reference list are neither, and in a policy they occupy more pages than the actions do.
Spend the non-steps rather than drawing them
The third pile is harvested, not discarded. A scope exclusion becomes a decision at the front with an ending of its own. A defined term becomes the criterion on the decision that uses it, with its exact wording in that row's comment. The responsibilities table becomes the lane set. Nothing in the pile becomes a box.
Type the actions into rows
In QueryChart every row is a box, so put one marked action in each row's Box text column, in the order the actions happen rather than the order they were printed. Keep the label short enough to read at a glance and leave the clause it came from in the step's comment. Then join the rows with the Line to column, which takes row numbers.
Give every condition a labelled exit
The rows that came from conditions become diamonds: switch their Shape column to Decision and rewrite each as a question. Line text then takes one label per branch, in the order of the numbers in Line to. A clause naming three cases needs three labels ("Low risk", "Medium risk", "High risk") or a reader cannot tell which route is theirs.
Place the routes the document scattered
Point each branch at the row it reaches, backwards included: an authorisation needing more work returns to the technical basis, and a temporary change at its expiry date re-enters the same review. Then fill the Horizontal lane and Vertical lane columns from the responsibilities table, so a step sits in "Screening" under the "MOC coordinator".
Read the chart back against the document
Go clause by clause and tick each one off against a row, a branch label, a lane or a step comment. Three things are left over: detail that belongs in a comment, a route nobody has drawn yet, and clauses the site stopped following years ago. Take that last list to whoever owns the document: it is the revision request the mapping earned.
Mistakes to avoid
Drawing a prohibition as a step
"No change shall be implemented before authorisation" is not something anybody does; it is a claim about the topology. Satisfy it by checking that nothing reaches implementation except through the gate, not by adding a box.
Six boxes nobody performs
A list of who is accountable for what is not a sequence, and transcribing it produces six boxes in a row that nobody performs. Roles belong in the lane columns, attached to the steps that actually happen.
Whole clauses pasted into a label
A box carrying forty words of policy language cannot be read at the size a diagram is read at. Keep the instruction in the label and the wording in the step's comment, where the original text stays available to whoever wants it.
Believing the document over the plant
A written procedure records what was approved, not what is done. Walk the chart with the people who run the process; where they describe a route the document has no clause for, the document is the thing that is wrong.
Turn your document into a flowchart
Open the management of change example as your own chart, then draw only the passages of your own document that describe somebody acting.
Related guides
Frequently asked questions
How do I turn a PDF into a flowchart?
Extract the text first and convert the text, not the layout. A PDF's reading order is a design artefact (columns, sidebars, tables and footers interleave), so anything that follows it produces boxes in an order the process never had. Pull the actions out, mark the conditionals, and build from that list. Pasting the extracted text into QueryChart's AI gets a usable first draft of the rows; the conditionals it could not resolve are the part that needs a person.
Where do scope and definitions go in a flowchart?
Neither becomes a box. A scope statement becomes a decision at the front of the flow with an ending of its own: in the example here the policy's exclusion is "Replacement in kind?", and the "In kind" branch stops at "Handled as maintenance work" without touching the rest of the process. Definitions become the criteria on the decisions that use them (low, medium and high risk are only decidable as branch labels because the document says where each band begins), and the exact wording goes in the step's comment.
Why do flowcharts made from documents come out too long?
Two mechanisms, and both are avoidable. The first is transcription of the sections that describe no work: a responsibilities table contributes one box per role, a reference list one per document, and neither describes anything anybody does. The second is inflation at the decisions: one sentence naming three cases drawn as three steps in a row instead of one diamond with three labelled exits, so the chart grows while the branching stays invisible. Between them they add a dozen boxes to a twelve-step process.
Can a policy or a contract be drawn as a flowchart?
Yes, and the exercise usually finds something. Contracts and policies are written to allocate obligation rather than to sequence work, so their conditionals are dense and their actors are named once and then referred to as the party or the recipient. Drawing one forces every obligation into an owner's lane and every condition into a labelled branch, which is how the clause with no stated consequence and the notice period with no step behind it come to light.