Choose a document management system through 3 distinct controls: version history, appropriate access and an explicit retention decision. A folder full of files is not enough. Staff need to identify the record they should use, understand who may change it and know what happens when it is replaced or no longer needed.
Compare SharePoint with Microsoft Purview and Nextcloud against the document task you need to control. The opened documentation establishes different mechanisms, without ranking either product universally best or defining your organisation’s legal retention schedule.
| Buyer requirement | SharePoint with Microsoft Purview | Nextcloud | Selection test |
|---|---|---|---|
| Retrieve earlier content | Library version history can track and restore versions when enabled | Versions sidebar supports rollback and downloading a version | Recover a fictional revision with an ordinary authorised role |
| Distinguish draft from issued content | Major/minor versions and visibility depend on library configuration | Opened version guide describes history, not an equivalent publication-approval model | Demonstrate how readers identify the issued instruction |
| Govern access | Library permissions affect visibility of versions | Sharing supports public links and internal users or groups; administrator configuration can restrict options | Test readers, editors and shared links separately |
| Preserve records | Purview supports retention policies and item-level labels | Ordinary version history automatically expires older versions; named versions are excluded from that automatic expiry | Determine preservation requirements separately from editing convenience |
| Recover information when leaving | Version restoration is documented; complete migration scope needs its own evidence | A version can be downloaded using its timestamp; complete migration scope needs its own evidence | Request a sample export with metadata and access implications explained |
Nextcloud’s version-control manual explains automatic expiry and named-version exceptions. Its sharing manual documents configurable link and internal sharing. These features establish useful alternatives for collaboration, but the opened pages do not establish a Purview-equivalent legal-hold system. Keep that requirement unresolved until the proposed configuration has supporting evidence.
How should version history and access identify the usable document?
Start with the document’s business purpose. A working draft, an issued instruction and a retained historical record should not be confused merely because their filenames look similar. Decide which state people should use for the relevant task, who may advance it and what evidence should explain the change. Avoid calling every saved file an approved record.
Microsoft’s versioning guide describes storing, tracking and restoring versions when versioning is enabled in a list or library. That provides a concrete capability to evaluate. Ask the demonstrator to show an earlier version and explain how it relates to the current one, rather than accepting a checkbox saying version history exists.
The guide distinguishes major versions, typically representing a milestone, from minor or draft versions that are works in progress. Keep that distinction connected to your actual workflow. A major version can support publication discipline, but its number alone does not prove that the required business approval occurred. The approval rule and the evidence it requires need to be defined separately.
Access affects which version someone can see. The same documentation explains that some current versions are visible only to users with the relevant permissions. Test the ordinary reader as well as the editor. A correct document seen by an administrator does not establish that staff following the issued instruction will see the same state.
Version limits also matter. The guide notes that earlier versions can be removed when a configured limit is reached. Do not promise unlimited history from the presence of a versioning feature. Establish the actual configuration and its relationship to any separate retention requirement before treating old versions as permanently available.
Use this original lifecycle map to define the intended states. It is a proposed operating model, not an assertion that a particular library already enforces it.
| Document state | Intended user | Evidence to retain | Question to test |
|---|---|---|---|
| Working draft | Authorised editors | Source and change context | Can ordinary readers mistake it for issued guidance? |
| Ready for decision | Named decision owner | Relevant version and outstanding questions | Is the decision attached to the right content? |
| Issued record | Intended readers | Current reference and decision evidence | Can staff find the usable version? |
| Superseded record | Authorised historical access | Relationship to replacement | Is it clearly distinguished from current guidance? |
| Retained record | Appropriate custodian | Retention basis and configuration | Is preservation behaviour understood? |
| Disposition candidate | Authorised decision route | Applicable rule and unresolved holds | Could deletion remove material still needed? |
How do retention decisions differ from ordinary version control?
Microsoft’s retention overview describes retaining content, deleting content or retaining it and then deleting it. Those are materially different outcomes. Write the intended business decision before configuring a policy. Do not copy an example duration from product documentation and present it as your organisation’s legal requirement.
The overview distinguishes policies that apply settings at a site or mailbox level from labels used at an item level. That helps frame a practical choice: should the same rule cover a location, or do documents in that location require different treatment? Establish the record categories and the applicable basis rather than forcing all documents into one convenient schedule.
Keep preservation behaviour separate from what users see. Microsoft describes retained copies in protected locations when covered content is edited or deleted. An ordinary user removing a file from view does not necessarily mean every retained copy is gone. Your document policy and user instructions should reflect the actual configuration instead of promising deletion from one visible action.
Do not present a retention label as proof of complete compliance. The product provides mechanisms; the organisation must identify the applicable records, responsibilities and legal basis. This guide does not determine those requirements or claim that a particular configuration has been assessed. Where the retention question is unresolved, retain it explicitly before activation.
Rehearse version recovery with fictional material. Create a draft, change it and retrieve the earlier content in a controlled library. Record which role performed the task and what became the current version. The result should explain the recovery path without changing an operational instruction used by real staff.
Test a user who should not edit or view a restricted record. Include exports and shared links in the access discussion, rather than checking the library screen alone. The proposed system should demonstrate the intended boundaries for the actual roles and content. Do not assume a document remains restricted after it has been copied into another location.
Finish selection with evidence about the document lifecycle, roles, configuration and unresolved requirements. Keep document history, business approval and legal retention as related but separate records. For related application requirements, see Spout’s web development page. Get started with a redacted lifecycle map and the task staff cannot currently perform, keeping confidential documents and tenant credentials outside the initial enquiry.
By Spout Team. AI-assisted drafting by Codex, grounded in the linked primary documentation.