What is version control for documents, SOPs and processes?
Most "what is version control" results assume Git and source code. This defines it for documents, SOPs and processes instead, and separates it from revision control, change control and document control.
A worked example, stage by stage
A draft starts at 0.1, not 1.0
The chart opens on "New document drafted" and moves straight to "Assign initial draft version 0.1": a decimal, because nothing before formal approval is ever given a whole number in this scheme.
The review loop advances the minor version
"Circulate draft for internal review" and "Reviewer evaluates the draft" feed "Changes required?". A Yes routes through "Increment the minor version" (0.1 becomes 0.2) into "Revise the draft against comments", which loops back on a branch labelled "Re-review" for as many cycles as the draft needs.
A whole number is earned, not assumed
"Submit final draft for approval" and "Approver reviews the final draft" lead to "Approved for issue?". A rejection loops back to "Increment the minor version"; an approval reaches "Assign major version 1.0" and a File-shaped row, "Update the version history register", that logs it.
Publishing retires the old version on the same row
"Publish the approved version" is immediately followed by "Mark the previous version superseded", so the prior revision is retired the moment the new one goes live. A reader requesting a change re-enters at "Reopen the document at the next version"; everyone else reaches "Current version remains in force".
How it works
Pick one location as the authoritative version
Every other copy (a PDF emailed out, a printout, a page saved to a shared drive) is a copy of that one location, not a second original. If two places can both claim to be current, you do not have version control yet, whatever your numbering looks like.
Separate draft numbering from published numbering
Use decimals for anything still in review and reserve whole numbers for what has actually been approved, the way 0.1 through 0.3 lead up to 1.0 in the example chart above. A reviewer citing "the comments on 0.3" is then unambiguous about which draft they mean.
Log who changed what, not just that something changed
A date stamp on its own tells a reader nothing about what actually moved. Record the actor, the field, and the before-and-after value for every edit, which is what QueryChart's Change Log does automatically for every chart, with no setup required.
Make two versions comparable, not just viewable
Being able to open version 3 and open version 5 is not the same as being able to see what changed between them. QueryChart's Compare Versions view sets any two revisions side by side so the difference is the thing you're looking at, not a guess.
Treat restoring an old version as routine, not an emergency
If reverting a bad edit means asking someone with database access to intervene, your version control exists on paper only. Restoring a prior version should be an action any authorised editor can take themselves, the moment they notice the problem.
Frequently asked questions
Is version control the same thing as revision control?
Yes, in practice. The two terms describe the same underlying idea (one current version plus a retrievable history of every prior one), and different organisations, tools and standards simply prefer one word over the other. Nothing about the mechanics changes depending on which term you use; see /guides/revision-control-vs-version-control for the full comparison.
What's the difference between version control and change control?
Change control decides whether a change should happen at all: its impact, who approves it, how to roll it back if it goes wrong. Version control is what records the result once that decision is made: the new number, the timestamp, the actor. A change control process can exist without version control, badly, and version control without change control just means nobody decided the change was a good idea before it was numbered. See /guides/version-control-vs-change-control and /guides/how-to-create-a-change-control-process for the CAB and rollback mechanics.
Does version control work the same way for documents as it does for code?
The core idea is identical (one authoritative current version, a full history of what preceded it, a record of who changed what) but the mechanics differ. Code version control such as Git is built around branching and merging concurrent lines of work; document and process version control is usually linear, one draft moving through review to a single approved version, which is closer to what this page and the example chart describe.
Is QueryChart's audit trail turned on by default?
The version history described on this page (Change Log, Compare Versions, restore) is free and runs automatically on every chart with no setup. QueryChart's compliance audit trail, a hash-chained record mapped to ISO 27001, SOC 2 and HIPAA controls, is a separate, paid capability an organisation turns on deliberately. It is not switched on by default and not something every account already has running.