Tools & workflows
Keep version history separate from approval status
A saved revision tells you what changed. An approval record tells you what somebody authorised. Those are different facts.
The newest file is not necessarily the approved file. A writer may correct a heading after review, a subject specialist may add a qualification, or an automatic save may capture an unfinished sentence. Treating recency as approval allows work to move forward without anybody consciously accepting the change.
Version history is useful for seeing or recovering earlier material. For example, Microsoft's SharePoint documentation describes restoring an earlier revision when version tracking is available; restoring creates a new current copy rather than removing the earlier version. That is a recovery mechanism. It does not tell your team whether the restored wording is authorised for publication.
Attach approval to an identifiable state
When an approver accepts a document, record the item, the identifiable revision or snapshot, the scope of approval and the date. A short record might say that the service description in revision three is approved for the website, while the pricing panel remains outstanding. That illustrative wording is more useful than ‘Looks good’, especially when several components move at different speeds.
If your tool cannot identify a stable revision, keep an agreed handover copy in a clearly designated location. Link to that copy from the approval record and restrict casual editing according to your team's process. Do not rely on a screenshot of one paragraph to stand for approval of an entire document.
Decide what reopens review
Not every edit needs the same response. Agree in advance how the team handles spelling corrections, factual changes, new claims and changes to scope. A minor punctuation fix might be handled by the editor; a changed service promise may need a new decision from its owner. These boundaries should fit the work, not simply the convenience of the publishing schedule.
Keep a brief change note when a revision follows approval. State what changed, why and who accepted it. If the change is outside the existing approval, make the pending status visible. Avoid describing the whole item as unapproved when only one separable component needs attention, but do not conceal that component inside an otherwise approved package.
Test the arrangement with an absent colleague. Can they find the publishable version and explain the remaining restrictions without asking the author? If they must guess from filenames or reconstruct a long chat, simplify the record. Good version history and clear approval complement one another; neither replaces the other.
