Version control vs document management

A worked example, stage by stage

1. A change is requested: no version exists yet

   The Start row is an occurrence, "Document need or change identified", flowing straight into "Raise a document change request". This is workflow routing, the document-management function of capturing why a change is needed, and it happens before anything has a version number.

2. One row mints the version; the rest is approval routing

   "Draft or revise the content" enters a review loop ("Carry out technical review", the "Comments to resolve?" decision, "Update the draft against comments") then the Approver's "Approve for issue?" gate. Only "Assign version and effective date" is version control; the rest is workflow routing.

3. Register, access point and withdrawal are document management, not versioning

   "Update the master document register" is metadata and classification, written as a File row so it shows on the diagram. "Publish to the controlled location" is access control: one authoritative place, not a copy. "Withdraw superseded copies from use" is distribution control, and none of the three is stored in a version number.

4. Retention and periodic review outlive any single version

   Training or "Read and acknowledge the new version" precedes "Use the current controlled version", then "Trigger the scheduled periodic review" reopens the record on a timer. "Document still valid?" exits to "Record outcome and next review date", back to the change request, or "Document withdrawn and retired": a retention schedule, which version control alone does not run.

How it works

1. Name what you're actually missing

   If nobody can answer "who changed paragraph 4 last week, and what did it say before," you're missing version control specifically. If the gap is instead "who's allowed to edit this" or "where's the one copy people should trust," that's a document management gap that a version history alone will not close.

2. Check what a version history actually returns

   A real one shows a change log with per-actor, per-field differences (not just a modified date) plus a way to compare any two versions side by side and restore an old one. QueryChart's Change Log and Compare Versions view, at /features/version-control, are a working example of what to expect before you accept a tool's claim of "version history."

3. Locate the other four functions separately

   Access control (who can view or edit), metadata and classification (how the document is found), retention scheduling (how long it's kept and when it's reviewed), and workflow routing (how a draft becomes an approved, issued document). None of these live inside a version number, so audit each one on its own rather than assuming a version history covers it.

4. Don't buy a whole discipline to get one mechanism

   A heavyweight document management system is justified when you need all four functions above enforced together. If what's actually missing is the ability to see what changed and revert it, that's a much smaller problem, and a chart tool with a real change log solves it without the rest of the rollout.

5. Map the distinction onto your own process

   Draw your document's lifecycle as rows and mark which single row mints a version, the way the chart below marks "Assign version and effective date." Everything else in the diagram is document management, and seeing it laid out that way is usually enough to settle which one a team is actually short of.

Frequently asked questions

Is version control part of document management, or separate from it?

Part of it. Document management is the governing discipline (access, classification, retention, workflow and versioning together) and version control is the mechanism inside it that tracks successive revisions of a document. Treating them as separate options to choose between is the misconception this page exists to correct: a document management setup with no version control is missing a core function, and a version history with no access control or retention policy around it is not yet document management.

Do I need a full document management system just to get version control?

No. Version control is the narrower capability (a change log with per-field, per-actor differences, a way to compare two revisions, and a restore path) and a chart tool can provide that on its own, free and always on, the way QueryChart's version history does; see /features/version-control. A full document management system is the right purchase when you also need enforced access permissions, formal classification and a retention schedule running across many documents, not when the real gap is just seeing what changed.

How is version control different from change control?

Version control tracks the successive states of one document: what changed between revision 3 and revision 4. Change control governs the decision to make a change at all, typically through an advisory board, a risk assessment and a rollback plan, most often for IT systems or operational processes rather than a single file. A document control process uses both: change control-style approval gates before a revision is issued, and version control to record the revision itself. /guides/version-control-vs-change-control covers the distinction in full.

Where does version control sit inside a document control process?

At a single point: the step that assigns a version number and an effective date once a revision is approved. Everything before it (the change request, drafting, review) and everything after it (publishing to the controlled location, withdrawing the superseded copy, training, periodic review) is document management doing work that a version number by itself cannot do. /guides/how-to-create-a-document-control-process walks the full twenty-row process these stages are drawn from.