How to track changes in a process
How to track changes in a process: QueryChart's Change Log names who edited a decision rule or threshold, the field's previous value, and its current value, so nobody reconstructs an edit from memory.
A worked example, stage by stage
Where an edit starts
The chart opens at "Document submitted for approval," then asks "New document or revision?" and, for a revision, "Editorial or substantive change?" before splitting into "Log the editorial correction" or a full "Regulated document type?" check: the branch that decides how much scrutiny a change gets before anyone reviews it.
The review loop that surfaces disagreement
Rows six through nine run the review itself: "Add quality and regulatory reviewers," "Collect reviewer comments," then "All review comments resolved?", which, if not, asks "Can the author resolve now?" before looping back or exiting to rework. Every pass through this loop saves as its own version.
The threshold this guide's example edits
"Approver reviews the final draft" leads to "Approve for release?," then to the row the worked example above is about: "Second approver required?," which routes to "Obtain the second approval" when the answer is yes. Raise that row's threshold and the Change Log records exactly that edit.
Release, and the record it leaves
The Release lane closes the tree three ways: "Published as a minor editorial update," "Published after full approval," or "Published with training assigned" after "Read-and-understood required?", plus "Returned to the author for rework" and "Rejected and closed." Every rule that routed a document to one of these sits in a version Compare Versions can open.
How it works
Open the Change Log after an edit
Every save writes a new version, and the Change Log lists them in order. Open it from the chart's history panel to see which version changed and who saved it: you don't need to know in advance that a threshold moved.
Read the entry: actor, field, previous value, current value
Click into a version and its entry names the person who edited it, the field they touched (a row's label, a branch's condition, a lane assignment) and the value it held before against the value it holds now. That is the whole answer to who changed the second-approver threshold and what it used to say, without opening a single email thread.
Use Compare Versions when one entry isn't the whole story
A single edit's entry is precise but narrow. When several rows moved between the version you trust and the one in front of you, open Compare Versions instead and read the two side by side, the same mechanism, widened to every field that differs.
Restore the prior version if the edit needs to be undone
If a raised threshold turns out to be wrong rather than intentional, restore the version that preceded it. Restoring replaces the current chart with that revision outright, rather than asking someone to retype the old rule from memory.
Name the rule, not just the branch, so the diff stays legible
Write a decision row's label and its branch labels around the actual trigger: "Second approver required?" answered "Required" or "Not required", rather than a bare yes or no. A Change Log entry that names a labelled field is far more useful than one that says an unlabeled box moved.
Frequently asked questions
What exactly does the Change Log record when a process changes?
For every edit, an entry naming the person who made it, the field they changed (a row's label, a branch condition, a lane assignment) and that field's value before the edit against its value after. Raising a second-approver threshold from $5,000 to $10,000 produces an entry that says precisely that, attributed and timestamped, without anyone maintaining a separate log. The mechanism is covered in full at /features/version-control.
Is tracking process changes the same as change control?
No. Tracking a change is the record QueryChart keeps automatically after an edit happens: who, what field, old value, new value. Change control is the decision process that governs whether an edit should happen at all, usually with a request, a review step and a rollback path. Both matter, but they answer different questions; the mechanics of the second are at /guides/how-to-create-a-change-control-process.
How is this different from tracking changes in an SOP?
The Change Log itself is identical (same actor, field, and before/after values) because a decision tree and a written procedure are both charts under the same version history. The difference is what typically gets edited: a process like this one changes branch conditions and routing, while an SOP more often changes step text and responsibility. See /guides/how-to-track-changes-in-an-sop for that version of the same feature.
Can I see everything that changed between two versions, not just one edit?
Yes: open Compare Versions rather than a single Change Log entry, and it lays two revisions side by side with every differing field marked. That is the tool for a rule that has drifted over several small edits rather than one obvious one.
Does restoring an old version delete the edit that changed the threshold?
No. Restoring makes an older version current again, but the version where the threshold changed still exists in the chart's history: its Change Log entry is not erased, so the record of who raised it and when survives the restore.