Version control for process documentation and process maps
How version control applies to process documentation (procedures, work instructions and process maps) and why an outdated diagram misdirects the person doing the work, not just the reader.
Version control for process documentation means giving procedures, work instructions and process maps the same identifier, revision, authoritative location and review interval as any other controlled document, plus one added requirement: a stale diagram has to be withdrawn from the point of work, not just replaced in a file.
The short version
- A process map needs the same four controls as a written procedure: identifier and revision, one authoritative location, a superseded-copy withdrawal, and a dated review interval.
- A step added, an owner reassigned, or a decision branch relabelled is a revision, even though no paragraph changed and no word count moved.
- A diagram is trusted more than prose at the point of work, which is exactly why an old one left in place misdirects rather than merely misleads.
- Track who changed which lane, row or connector, compare any two versions side by side, and restore an earlier one, the same version history a text document gets.
- Withdrawing a superseded diagram means finding every printout and every embedded copy, not just replacing the file at the authoritative location.
Choosing documentation tools
A diagram is followed, not just read
A paragraph in a procedure is read, then interpreted, then acted on: three separate steps a reader can catch themselves failing at. A flowchart pinned at a workstation skips straight to acted on. Someone glancing at a process map trusts its shape more than they would trust a sentence, because a diagram reads as a fact rather than as someone's account of one, and that trust is exactly what makes a stale diagram dangerous: it doesn't just mislead the person reading it, it misdirects the person doing the work while they are doing it.
Process documentation (procedures, work instructions, process maps, RACI charts) needs the same four things any controlled document needs: a unique identifier and revision, one authoritative location, a superseded-copy withdrawal, and a dated periodic review. /guides/how-to-create-a-document-control-process walks the whole lifecycle those four properties sit inside. What changes for a diagram specifically is smaller and easy to miss: a step added or removed, an owner reassigned, a decision branch relabelled: none of them touch a word count, so none of them read as a revision unless the process treats every layout change as one.
This page stays tool-agnostic: the discipline holds whether the map lives in a drawing tool, a wiki page, or a chart. /guides/version-control-for-flowcharts covers the narrower, product-specific version of the same problem: what a Change Log records field by field on an actual flowchart. Here, the walkthrough below uses QueryChart's document-control-process chart because it is a real, working example of the four properties, tracked automatically by the version history described at /features/version-control.
One process map, walked stage by stage as a controlled document
The document-control lifecycle used as a working example of a process map under version control, the same chart, revealed lane by lane, from the reason for a change to the review date that reopens it.
A revision starts with a reason, not a redraw
The Start row, "Document need or change identified," and the row after it, "Raise a document change request," both happen before anyone touches the diagram itself; for a process map the reason for the change has to be recorded in exactly the same way it is for a paragraph.
Redrawing is drafting
"Draft or revise the content" now includes redrawing a step, retargeting a decision branch, or moving a box to a different lane, and "Comments to resolve?" sends that layout change back through "Carry out technical review" the same way a wording comment would.
The version assigned to a diagram
The Document controller lane assigns a version and effective date, writes it to "Update the master document register," publishes it, then runs "Withdraw superseded copies from use": for a diagram that withdrawal step means the printed flowchart pinned beside the machine, not only the file on the shared drive.
A diagram in use still has a review date
Training or "Read and acknowledge the new version" comes before "Use the current controlled version," and the scheduled review at "Document still valid?" gives the diagram the same three outcomes as any controlled document: "Valid" logs the date, "Revise" loops back to the change request, "Retire" ends at "Document withdrawn and retired."
How it works
Treat a layout change as a revision
A moved decision branch, a reassigned lane, or a relabelled step changes what a reader does next just as much as a rewritten paragraph does. Give your process maps the same revision trigger as your procedures: any change that alters what happens, not only a change that alters what is written.
Put the version and date on the diagram itself
Print the identifier, revision number and effective date on the chart, not only in the file name or the register that references it. Someone looking at the diagram on a screen or a printout should not have to go and find a separate record to know whether it is current.
Keep one authoritative diagram, everywhere else a link
Every embedded copy in a wiki, a training deck, or a supplier pack should link to the authoritative version rather than hold a pasted export of it. A pasted image stops updating the moment someone exports it.
Log who changed which row, not just that something changed
A useful diagram history names the field: this box's label, this connector's target, this lane's order, changed by this person on this date. QueryChart's Change Log records exactly that on every chart automatically, and Compare Versions puts two revisions side by side: see /features/version-control.
Withdraw the printed copy, not only the old file
A flowchart pinned at a workstation outlives the file it was printed from. Walk the points of use (noticeboards, machine stations, induction packs) the same way you would for a text procedure, and replace or remove each one when a revision is issued.
Mistakes to avoid
The pinned printout
A flowchart taped up next to a machine is the diagram equivalent of an uncontrolled printout, and it is usually the one an auditor finds first. List the points of use before you issue the next revision and replace the printed copy in the same withdrawal step: the full request-to-retirement lifecycle around it is covered in full at /templates/document-control-process.
A relabelled decision branch with no changelog
Renaming "Approved" to "Approved with conditions," or moving a Decision row's Yes branch to a different downstream step, changes the process without changing a single sentence anywhere. If your version history only tracks file saves, that revision is invisible.
One export, many stale copies
A PNG or PDF pasted into a wiki page or a training deck is a snapshot, not a link: it will not update when the source diagram does. Every place that references the process map should point at the authoritative version, not at a file someone exported from an old one.
No owner for the diagram, only for the process
A process can have a named owner while the map depicting it belongs to nobody in particular, which is how it goes three reorganisations without being touched. Give the diagram itself a reviewer and a review date, not just the procedure text beside it.
Related QueryChart feature
Create your own version-controlled process map
Open the document-control example as your own chart, and every row, lane and connector you change from here is tracked in its version history.
Related guides
Frequently asked questions
Is a process map a controlled document?
Yes, if it carries the obligations a controlled document carries: an identifier and revision, an approval record, one authoritative location, and a review interval. Format doesn't decide the question: a flowchart, a RACI chart and a written procedure can all be controlled documents, and a diagram that skips version control while the procedure text next to it has it is not actually controlled, it just looks tidy.
What counts as a version change on a process map, if no text changed?
A step added or removed, an owner reassigned to a different lane, a decision branch relabelled or retargeted, or the sequence of two steps swapped are all version changes even though no sentence was rewritten. The test is whether the change alters what someone reading the diagram would do next: if it does, it is a revision, not a formatting tweak.
How is this different from version control for flowcharts?
This page covers the versioning discipline any process map needs, independent of the tool used to draw it. /guides/version-control-for-flowcharts covers the same problem from inside a specific product: what a Change Log records field by field on an actual flowchart, and how Compare Versions and restore work in practice.
Does process documentation need the same version control as a text SOP?
Yes: the four properties, identifier and revision, one authoritative location, superseded-copy withdrawal, and a dated review, apply regardless of format. What differs is only the failure mode: an outdated paragraph misleads a reader who has to interpret it, while an outdated diagram is followed directly, which is why the withdrawal step matters even more for a process map than for a page of prose.