How to track changes in an SOP
How to track changes in an SOP: what a revision history entry has to record (what changed, who changed it, when, why, and which version it replaces) plus the safety-critical fast-track split.
Tracking changes in an SOP means logging a dated revision history entry (what changed, who changed it, when, why, and which version it replaces) rather than relying on inline redlines.
The short version
- A revision history entry needs five fields: the SOP/step affected, what changed and why, the effective date, the author, and the version it supersedes.
- Safety-critical steps take an expedited review path; everything else takes the standard review cycle.
- Check the log for a pending entry against the same SOP before drafting a new one: two open entries produce two competing version numbers.
- Finalizing an entry locks its date, approver and version numbers so the record can't be silently rewritten later.
- For a chart-based SOP, QueryChart's Change Log records every field-level edit automatically: see /features/version-control.
The record is an entry, not a redline
"Track changes" is Word and Google Docs language: a comment bubble and a strikethrough living inside the file itself. An SOP that borrows the phrase but not the mechanism ends up with its change history scattered across email threads and tracked-changes copies nobody merged, and a procedure owner who cannot say with certainty what changed in the last revision, when, or why. Tracking a change in an SOP means something narrower and more durable: a dated entry in a revision history log that records what changed, who changed it, when, why, and which version it replaces.
Every entry needs the same fields regardless of who writes it or what changed: the SOP and step affected, a plain-language description of the change and the reason for it, the effective date, the author, and, the field most logs miss, the exact version number the entry supersedes. A change to a safety-critical step earns an expedited review path rather than waiting behind the routine queue, and before drafting starts the log itself gets checked: is there already a pending entry open against this same SOP? Two open entries against one procedure produce two candidate version numbers, which is a problem the log has to solve before anyone can trust it.
A chart-based SOP built in QueryChart does not need a hand-kept log for the fields a revision history exists to capture. Every edit to the chart is already recorded automatically, field by field, in its Version History panel: open it and a Compare Versions view shows exactly what changed between any two saved versions and who changed it, and one click restores an earlier one without losing what came after. The manual entry below still matters where the SOP's content lives outside the chart, or where a standard names a revision history log as its own artifact; see /features/version-control for what the built-in version is doing underneath without anyone maintaining it by hand.
One proposed change, tracked to a finalized entry
A single proposed change to an SOP, tracked row by row from the moment it's identified to the finalized log entry naming the version it replaces.
What gets recorded, before anything else
The chart starts at "Change to an SOP identified," then "Describe the proposed change and the reason for it" (the SOP, the step, what's changing, why, and the effective date) before "Change affects a safety-critical step?" decides which review path the entry takes.
The fast-track split and the duplicate check
A safety-critical change is "flagged for expedited review" while everything else is "routed through the standard review cycle"; both then hit "Revision history log already has a pending entry for this SOP?" before "Draft the revision history entry: date, change summary, author, version superseded" is written as a File row.
Two checks before an entry is trusted
"Reviewer checks the entry against the current SOP content" comes first; "Comments to resolve before approval?" loops an unresolved entry back through the SOP author for a re-review, and only then does the Approver check it against "the SOP master and the version it supersedes."
Finalized, then the old version is closed out
"Record the approved entry as final in the revision history log" locks the date, approver and version numbers before the SOP's own version number and effective date update, and "Withdraw or archive the version referenced as superseded" closes out the entry the new one replaced.
How it works
Record the five fields on every entry
Write down the SOP and step affected, what changed and why, the effective date, the author, and the exact version number this entry supersedes. An entry missing the superseded version leaves a gap in the log nobody can close after the fact.
Route safety-critical changes onto the fast track
Ask whether the change touches a safety-critical step before it goes to review. If it does, flag it for expedited review rather than letting it queue behind routine changes; if it doesn't, send it through the standard review cycle.
Check for a pending entry before you draft
Search the log for an entry already open against the same SOP before starting a new one. Two open entries against one procedure produce two candidate version numbers: coordinate with the other author or sequence the changes instead of drafting in parallel.
Lock the entry once it's approved
Record the approved entry as final, then update the SOP's version number and effective date and withdraw the version it replaces. An entry that stays editable after approval is not a record, it's a draft with an approver's name on it.
Let the Change Log do the recording for a chart-based SOP
If the SOP itself is a QueryChart flowchart, skip the manual log for anything captured on the chart: every edit is already tracked field by field. Open Version History, use Compare Versions to see what changed between two saved versions, and restore an earlier one in a click: see /features/version-control.
Mistakes to avoid
The entry with no superseded version
A revision history entry that records what changed but not which version it replaced can't be reconstructed into a timeline later. Make the superseded version a required field before drafting starts, not an optional note.
Two open entries for one SOP
Two authors starting revision history entries for the same SOP in the same week produce two competing version numbers. Check for a pending entry before drafting, and coordinate rather than reconciling the collision after both get approved.
Redlines instead of a log
Tracked-changes files passed around by email scatter the actual sequence of who-changed-what-when across inboxes. A dated log entry, or a chart's own Change Log, is a record; a redlined attachment left in someone's inbox is not.
Confusing one entry with the whole program
Getting a single entry right doesn't fix a numbering scheme that drifts or a review interval nobody tracks: that's the governance layer at /guides/how-to-manage-sop-revisions. This page is about one entry; that one is about the cadence across all of them.
Related QueryChart feature
Build your SOP's revision history log
Take the revision history log as your own chart, set the fields your entries record, and let Version History track every edit after that automatically.
Related guides
Frequently asked questions
Is "track changes" the same as version control for an SOP?
Not quite. "Track changes" is document-editor language for inline redlines and comments inside one file. Version control for an SOP is the practice of giving each approved state of the procedure its own identified version and keeping a record of what changed between them; a revision history entry is how that record gets written down. See /guides/version-control-for-sops for the fuller distinction.
What does a revision history entry need to record?
Five things regardless of who writes it: the SOP and step affected, a plain-language description of the change and the reason for it, the effective date, the author, and the exact version number the entry supersedes. Missing the superseded version is the single most common gap in a revision history log.
Do all SOP changes go through the same review?
No. A change to a safety-critical step takes an expedited review path rather than queuing behind routine changes, while everything else goes through the standard cycle. Both paths converge on the same duplicate check before drafting: is there already a pending entry open against this SOP?
How is this different from managing SOP revisions generally?
This page is about the mechanics of one entry: the fields it needs, the review split, the duplicate check. The numbering scheme, review interval and who owns the schedule across every SOP is the governance layer, covered at /guides/how-to-manage-sop-revisions.
Does QueryChart replace the manual log?
For a chart-based SOP, yes for anything captured on the chart itself: every field-level edit is recorded automatically in Version History, with a Compare Versions view and one-click restore: see /features/version-control. A manual log is still worth keeping where the SOP's content lives outside the chart, or where a standard names a revision history log as its own artifact, such as the fuller lifecycle at /templates/sop-controlled-sop-template.
