Client Delivery
Part of Project documentation and decisions
Finding the latest approved deliverable
Find the applicable project deliverable by checking its identity, version, approval outcome and reader access.
Find the deliverable in the agreed register or authoritative file location. Match its exact version to the project’s approval record. The newest file may be a draft. Before using or handing over a version, confirm who accepted it, when, and whether conditions apply.
Identify the deliverable
Search by a stable deliverable ID, descriptive title or owner rather than a filename containing “final”. Results may include working drafts, copies sent for comment and superseded exports. If several locations hold copies, establish which location controls the project record and compare file identities and versions.
If no authoritative location is agreed, have the deliverable owner resolve the ambiguity before a handover. A convenient task attachment is not automatically the applicable file.
Match the decision to the file
Check the approval record for the exact file or version reviewed, the authorised reviewer, outcome and date. Confirm that the file you can open has the same identity. If a decision refers only to “the design” and several versions exist, seek clarification rather than guessing.
An edit made after approval can create a newer version without extending the earlier acceptance. If a revision is pending or rejected, the previous approved version may still apply; confirm that in the project record. Record any conditions attached to acceptance.
Check the workspace’s approval meaning
SharePoint libraries can use versioning and content approval, but draft visibility and the version a reader sees depend on library settings and permissions. A reader without draft access may see the last approved version while an editor sees a newer draft. Version history can help identify earlier files; it does not, by itself, establish project acceptance.
Microsoft says that when required content approval is enabled for a library that already contains files, those existing files are marked Approved automatically. That status cannot, on its own, prove that the project’s authorised reviewer accepted each deliverable. If project acceptance happens through a separate process, use its decision record.
If a colleague cannot open the version named in that record, ask the library or project owner to resolve access. A downloaded copy should carry its identity and status so it is not mistaken for a newly approved version.
Draft vs Approved Version in SharePoint
- VisibilityReaders without draft access see only the last approved version.
- Version HistoryShows all versions but does not confirm project acceptance.
- Approval StatusExisting files in a library with approval enabled are marked 'Approved' automatically — this does not prove project-level acceptance.
- Project AcceptanceMust be confirmed through the project’s formal approval process, not just library status.
Key facts about SharePoint versioning and approval
- Auto-approved filesWhen content approval is enabled, existing files are marked 'Approved' automatically.
- Version history availabilityAll versions are visible in history, but approval status is not always tied to version number.
- Access-dependent visibilityReaders may not see drafts even if they exist; editors do.
- Project acceptance ≠ Library approvalLibrary status does not replace formal project acceptance records.
Leave a clear handover
Share the deliverable’s stable reference, exact version, approval outcome, date and authoritative location. State any acceptance conditions. If a replacement is awaiting review, identify it as pending and name the last approved version separately. A receiving person should be able to reach the file and the decision from that reference.
