Keep the working draft separate
A reader needs to know which instructions are current. An editor needs room to improve them. Keep those views distinct so an unfinished change does not become the team’s reference by accident. File names such as “FINAL-v3” are a weak substitute for an identifiable published version.
Define review before publication
Choose who prepares a change, who reviews it, and who can publish it. In SOPFlow, a procedure moves through draft, review, approval, and active states. Review policy and workspace settings determine requirements such as reviewer eligibility and independent approval. Check those settings against your own process.
A workflow decision records what was approved; it does not prove the instructions are correct. Review prerequisites, exceptions, linked material, and acceptance checks before making a version active.
Record even small corrections
Use a new draft when published instructions need changing, including a broken link or a typo. A small correction can still affect what someone does. Describe the change and apply the review process required for that procedure. Do not recommend editing a released version in place merely because the change seems minor.
Connect the change to training and runs
Publishing a new version does not mean earlier work used that version. Existing training sessions and runs retain their procedure context. Decide whether the change needs a new assignment, a new run, or a communication to the affected team. Check exported and printed copies separately.
Set review dates around the process
Choose a cadence based on process risk, how often it changes, and your obligations. A tool change, incident, or revised responsibility can trigger an earlier review. There is no single review interval that is right for every procedure.
Try tracing one real change
Start with the published reader, find the change notes and review decision, then inspect a related training or run record. Confirm the owner can identify the version used and explain the next action. Keep historical records under your organization’s retention policy.
Keep the reason for the change, reviewer decision, publication context and learning decision discoverable. Link the review register to these records rather than copying an old completion date into the new version. Check printed copies and external references as part of the change.
Choose a review cadence and download the review register.
Read the record that belongs to the work
In this fictional example, CS-001 version 1.1 adds receiving-owner acceptance. Record labels below are illustrative references for a pilot, not IDs exported from a customer workspace. Trace the procedure version and the decision attached to each record.
| Record to inspect | Version or context | Decision to verify |
|---|---|---|
| Published procedure before the change | CS-001 v1.0 | Readers and new work use the applicable released instructions while v1.1 is being prepared. |
| Review of the proposed change | Draft v1.1 and its submitted review content | The eligible named reviewer checks the acceptance step and unavailable-owner exception. Approval and publication are separate decisions. |
| Completed learning record | Training T-001 retains its v1.0 context | Preserve what this learner actually received. Decide whether the changed task needs another assignment or practice. |
| Earlier work record | Run R-001 retains its v1.0 context | Read the steps and evidence belonging to that run. Evaluate active cases separately when the instruction changes. |
| New work after publication | The applicable active release is v1.1 | Check the version when starting the next run. Confirm the intended content before creating updated training. |
Before using the example
- Check ongoing work separately; decide how each active case should handle the changed instruction.
- If a change only corrects spelling, still use a draft and the configured policy, but explain why repeat training is unnecessary.
- If an earlier record has no clear version or source snapshot, keep that context unresolved rather than inferring it from today’s procedure.
Continue with a related task
Want to know why we built SOPFlow? Read the founder’s story.