Flowchart version control: how it actually works

A worked example, stage by stage

1. Draft picks up a decimal, not a guess

   The Start row is "New document drafted," and the very next row is "Assign initial draft version 0.1": the decimal identifies exactly how many review cycles the draft has been through, before "Circulate draft for internal review" and "Reviewer evaluates the draft" even happen.

2. Every rework bumps the number, not the guesswork

   At "Changes required?" a Yes answer routes to "Increment the minor version" before "Revise the draft against comments" begins, so a reviewer citing comments on a specific decimal is naming an exact, addressable draft rather than a vague "latest" file.

3. Approval is the one event that earns a whole number

   "Submit final draft for approval" and "Approver reviews the final draft" lead to "Approved for issue?": only the Approved branch reaches "Assign major version 1.0", so nothing before that point, however many decimal drafts it passed through, is ever mistaken for version 1.0.

4. Publication updates the register before anyone reads it

   "Update the version history register" runs before "Publish the approved version", and "Mark the previous version superseded" follows immediately after, so the register listing every past number, not just the live one, is current before a single reader reaches "Reader accesses the current version".

5. A later change reopens the record, it doesn't overwrite it

   "Change requested after publication?" either sends the process back to "Reopen the document at the next version" (restarting the numbered chain rather than editing the current file in place), or ends at "Current version remains in force", with every prior number still on record.

How it works

1. Stop naming versions in the file

   Retire the "v3_FINAL_reviewed(2)" convention entirely: a decimal or a colour typed into a filename is a label somebody added, not a record of what changed. Model the flowchart in a tool that keeps its own revision history, and let the filename go back to being just a filename.

2. Give every review submission a named version

   In QueryChart, submitting a chart for review saves a named version automatically, and nothing is ever overwritten. That one habit replaces the whole "Save As" trail of duplicate files, because the prior state is preserved whether or not anyone remembers to rename anything.

3. Open the Change Log before you ask what changed

   The Change Log lists every edit to the chart, who made it, and which field it touched, so "what changed since Tuesday" is a scroll through a list, not a memory exercise or a side-by-side squint at two exported images.

4. Diff two versions instead of eyeballing two exports

   Use Compare Versions to pick any two saved versions and see the difference field by field: box, connector, and label changes are called out individually as added, removed, or modified, rather than left for a reader to spot across two flattened PDFs.

5. Restore instead of rebuilding from memory

   If a revision turns out to be wrong, restore the earlier version rather than manually redrawing it from an old export. The restore itself becomes a new entry in the history, so nothing about the current draft's origin gets lost.

6. Keep the diagram as the master, not its export

   Treat the PDF or PNG you circulate as a snapshot for readers, never as the record you'd rebuild from: the editable chart with its version history is the one copy that can answer "what did this look like in March," and the export cannot.

Frequently asked questions

Is flowchart version control different from document version control?

Not in principle: both mean keeping every past state of something so you can see what changed and step back to it, but a flowchart's "changed" is structural: which box moved, which connector was added, which label was reworded. A document version control process built around prose and page numbers won't diff a decision branch. See /guides/version-control-for-process-documentation for the version of this problem scoped to a full process document rather than a single diagram.

Does exporting a flowchart to PDF count as version control?

No: it's a snapshot, not a history. A PDF captures one moment but can't be compared automatically against another PDF to show what changed, can't be edited back into, and carries no record of who made the prior change or why. It's useful for sharing a fixed copy with a reader; it isn't a substitute for the diagram's own version history.

What's the difference between the Change Log and Compare Versions in QueryChart?

The Change Log is the timeline: every edit, who made it, and roughly when, read top to bottom. Compare Versions answers a narrower question: pick any two saved versions and see the field-by-field difference between them, box by box and connector by connector, instead of scrolling the whole log to reconstruct it yourself.

Can I restore an old version of a flowchart without losing current work?

Yes: restoring a prior version in QueryChart creates a new version rather than deleting the ones that came after it, so the work done since stays in the history even though it's no longer the active state. Nothing about a restore is destructive.