Document version control best practices
Document version control best practices for teams that already have a numbering scheme: keep it stable, fix where version, date and approver appear, stop parallel edits of the current copy, and log every no-change review.
Document version control best practices are the habits that keep an existing numbering scheme trustworthy over years of turnover and volume, rather than the rules for choosing the scheme in the first place.
The short version
- Keep the numbering scheme stable once chosen: renumbering breaks every cross-reference that cited the old number.
- Print version, date and approver in the same fixed place on every page, not just in the file name or properties.
- Never let two people edit the "current" version in parallel without a lock or checkout convention.
- Decide upfront, in writing, exactly what makes a change major versus minor.
- Treat "no changes needed" as a recorded review outcome, not silence.
- QueryChart replaces the checkout convention with one canonical live chart: see /features/version-control.
A scheme is only as good as its second year
A numbering scheme rarely fails in its first month. It fails in its second year, when the person who set "whole numbers for issued copies" has moved on, a new document controller invents a slightly different rule to handle one urgent case, and two conventions start running through the same register at once. This page assumes the basic decision is already made: picking a scheme in the first place is covered at /guides/version-control-for-documents, and is about the handful of habits that keep a chosen scheme working once real volume, turnover and urgency hit it.
Four things go wrong after the scheme is chosen, and none of them are about the scheme itself. Renumbering an existing library to fix a perceived flaw breaks every cross-reference, training record and prior audit citation that named the old numbers, so it usually costs more than living with the flaw. A version number that lives only in a file name or a properties panel disappears the moment someone prints a page or forwards a screenshot, so it needs a fixed, printed position instead. Two authors editing the same "current" file in the same afternoon is not a numbering problem at all: it is a missing lock or checkout convention, and no scheme survives without one. And a periodic review that finds nothing wrong still has to leave a mark, or it is indistinguishable a year later from a review that never happened. None of this is the document's whole lifecycle (request through retirement is walked in full at /templates/document-control-process); it is the numbering layer inside that lifecycle, done well rather than merely done.
QueryChart removes one of these failure modes structurally instead of by policy. There is one canonical live chart per document rather than a set of files someone has to remember to lock, every save is captured automatically as a new entry in the Change Log with the actor and the exact field that changed, and Compare Versions puts any two revisions side by side. Two people cannot silently fork the "current" copy, because there is only one, and its whole history is a query rather than a memory test. See /features/version-control.
Where these practices show up in one document's life
The same 18-row document version control chart, read for what makes its numbering scheme hold up rather than for the numbering steps themselves.
The scheme starts before anyone reviews anything
"Assign initial draft version 0.1" happens immediately after "New document drafted," before "Circulate draft for internal review" or "Reviewer evaluates the draft": the decimal scheme is fixed at row two, not invented partway through the first "Changes required?" decision.
Rework increments, it never renumbers
"Increment the minor version" and "Revise the draft against comments" loop back into review on a branch labelled "Re-review" before "Submit final draft for approval" and "Approver reviews the final draft": the same decimal rule holds through every pass, so citing draft 0.3 still names one exact copy.
One decision draws the major-versus-minor line
"Approved for issue?" is the only row with a route to a whole number: the Approved branch reaches "Assign major version 1.0," while Rejected loops back to "Increment the minor version," then "Update the version history register," "Publish the approved version" and "Mark the previous version superseded" fix that decision in a File row before anyone reads the new copy.
A document that needs no change still gets a mark
"Change requested after publication?" is answered even when the answer is No: that branch ends at "Current version remains in force," a named outcome rather than an absence of activity, while Yes reopens the document at "Reopen the document at the next version" instead of starting a second copy alongside it.
How it works
Freeze the numbering scheme once real documents depend on it
Treat a change to the scheme itself (moving from whole numbers to semantic versioning, or redefining what a decimal means) as a project, not a tweak: it invalidates every existing cross-reference, training record and prior audit citation. If a flaw turns up, document the exception going forward rather than renumbering the library.
Put version, date and approver in one fixed spot on every template
Choose a single position (header or footer) and bake it into the document template so every author uses it without deciding. A version number in a file name or in document properties does not survive a printout, a screenshot or an email forward; one printed on the page does.
Give the "current" version a lock or checkout convention
Decide who may have the current version open for editing at once, and how a second author finds out someone already does: a checkout flag in the register, a locked file, or a single canonical live copy where only one save can win at a time. Without this, two approved edits landing on the same version is not a hypothetical.
Write the major-versus-minor rule down before the first document needs it
Specify, in the same document that defines the numbering scheme, exactly what triggers a whole-number step: formal approval alone, or approval plus a substantial rewrite. A team that decides this case by case ends up with two different documents both called version 2.0.
Record every periodic review, including the ones that change nothing
Give the review step a decision shape with a labelled "no change" exit that writes a dated entry to the register, the way "Change requested after publication?" reaches "Current version remains in force" instead of simply doing nothing. A missing entry should mean the review did not happen, not that nothing happened during it.
Let one canonical live copy remove the lock problem entirely
Open the document as a QueryChart chart instead of a set of files passed around by email, and there is only one current version to edit: every save is captured as a new entry in the Change Log automatically, so a checkout convention has nothing left to enforce. See /features/version-control.
Mistakes to avoid
Renumbering to fix a mistake
Discovering the scheme has a flaw two years in and renumbering the whole register to fix it breaks every citation that named the old numbers: audits, training records, cross-references in other documents. Document the exception going forward instead; live with the flaw in what is already issued.
The version number that only lives in the file name
"Policy_v3_FINAL.docx" tells nobody anything once it is printed, forwarded or copied without its name. Put the version, date and approver inside the document itself, in the same fixed place every time.
Two "current" copies edited in the same afternoon
A shared-drive copy and an emailed copy both get edited as though each is the master, and the two sets of changes silently overwrite each other or fork. Fix this with a checkout convention or, better, one canonical live copy: see /features/version-control.
A review that leaves no trace when nothing changed
A document reviewed and found still accurate, with no entry made anywhere, is indistinguishable a year later from a document nobody reviewed at all. Give "no change needed" its own dated line in the register, the way a decision row's No branch still reaches a named outcome.
Related QueryChart feature
Apply these practices to your own document
Open the document version control example as your own chart, and let one canonical live copy plus an automatic Change Log carry the rules on this page for you.
Related guides
Frequently asked questions
What's the single biggest document version control mistake to avoid?
Treating the scheme as fixed only until someone finds a reason to change it. Renumbering an existing library (even to fix a genuine flaw) breaks every cross-reference, training record and audit citation that named the old numbers, and that cost almost always exceeds the cost of living with an imperfect scheme. Fix problems going forward with a documented exception, not by touching what is already issued.
How do I stop two people editing the same "current" version at once?
Either add an explicit checkout convention (a flag in the register showing who has the document open, so a second author knows to wait) or remove the possibility structurally by keeping exactly one canonical live copy instead of files passed around by email or a shared drive. QueryChart does the second: every document is one live chart, every save versions automatically, and there is no second copy to fork. See /features/version-control.
What should count as a major version versus a minor one?
There is no universal rule, which is exactly why it has to be written down before the first document needs it rather than judged case by case. A common convention ties the major, whole-number step to formal approval alone (every draft revision in between, however substantial, stays a decimal), so "how big was the change" never has to be argued in the moment a version number is assigned.
Do I need to log a periodic review that found no changes needed?
Yes: an unrecorded review is indistinguishable from a review that never happened. Give the review step in your process a decision shape with a labelled exit for "no change needed" that still writes a dated entry to the register, the same way a chart's decision row records every branch it takes, not just the ones that lead somewhere new.
