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.
A worked example, stage by stage
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.
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.