Version control vs change control: what's the difference
Version control tracks which revision of a document is current and what changed; change control decides whether a proposed change is allowed to happen at all, and who has to approve it first.
A worked example, stage by stage
A request, not yet a version change
"Change to a controlled document identified" starts the chart, then "Submit document change request" and "Log the request against the document record": three rows of change control, and the document's version is still untouched.
Classification and approval gate everything
"Change classified as minor or major?" splits into a fast-track edit or a full review where the change reviewer "assesses the full impact" and records it against related documents and forms, before the "Approved?" decision, none of it has touched the version number yet.
Row 9 is where version control begins
Only once the change is approved does "Update version number and distribution list" run, followed by publishing to the controlled location, notifying distribution list holders, and withdrawing the superseded copy: the version-control half of the process.
Rejection loops back into change control
A "Rejected" answer sends the request to "Revise the draft and resubmit for review", which returns to the change reviewer's impact assessment; rework stays entirely inside change control until "Document reissued under formal change control" closes the chart with a new version in place.
How it works
Separate the two questions in your own process
Before you draw anything, decide what belongs to change control (request, classification, review, approval) and what belongs to version control (identifier, revision number, history, restore). Naming the boundary is the design step most flowcharts skip.
Classify before you assess
Route every request through a minor/major decision before assessment begins, the way row 4 does. A minor wording fix and a major requirement change should not travel the same review path, and deciding which is which up front stops every change getting the heaviest treatment.
Put the version-control step where approval actually ends
Only increment the version number, set the effective date and update the distribution list after the approval gate, never earlier. If your chart updates the version before the decision, you have described a process that versions rejected drafts.
Give change control its own reviewer, not the document owner
A change reviewer who assesses full impact and records it against related documents and forms, separately from whoever requested the change, is what makes "approved" mean something. In the example that step sits between classification and the approval decision, not folded into either.
Let version control run itself once change control has decided
Publishing, notifying distribution list holders and withdrawing the superseded copy are mechanical once a change is approved: that is the version-control tail of the chart, and it is the half QueryChart's Change Log and Compare Versions view already handle for you at /features/version-control.
Frequently asked questions
Is version control the same as change control?
No. Version control is the mechanism that identifies and remembers successive states of a document: a revision number, a history of who changed what, and the ability to compare or restore an earlier one. Change control is the governance process that decides whether a proposed change is allowed to happen, who reviews it, and what has to be true before it is approved. A document can have rigorous version control and no change control at all: every edit saved, nobody deciding whether it should have been made.
Which one should I build first?
Version control, because it is usually already running underneath you: QueryChart keeps a Change Log with per-field diffs and a Compare Versions view for every chart automatically, at /features/version-control. Change control is the part you have to design deliberately (categories, a reviewer, an approval gate) which is why it is the process worth drawing as a flowchart, like the one on this page.
How does this differ from revision control?
In practice, "revision control" and "version control" are the same mechanism under different names, both concerned with identifying and tracking successive states of a document. Change control is the different one: it governs whether a change is permitted in the first place, typically ending in a new version once approved. See /guides/revision-control-vs-version-control if it is specifically the revision-control/version-control naming question you are trying to settle.
Where does document control fit against these two?
Document control is the broadest of the three: the full lifecycle of a controlled document, from request through draft, review, approval, publication and eventual withdrawal or retirement. Change control and version control are both pieces of it: change control governs a single proposed edit, version control tracks the identifiers and history that edit produces. For the whole lifecycle rather than just the change/version boundary, see /templates/document-change-control-workflow or the broader /guides/how-to-create-a-document-control-process.