Version history is one of SharePoint’s most reflexively enabled features and one of the least thought-through — most teams turn it on, accept the defaults, and never revisit it. This post is about the strategy layer: what to actually decide about versioning, rather than just how to turn features on. None of what follows requires custom development — every decision here is a setting or a policy choice, just one that’s rarely made deliberately.
In this post: The default nobody questions · Intelligent Versioning: the current, better default · The real cost of approval workflows · Major vs. minor versions: a policy decision, not just a checkbox · Auditing what libraries are actually set to · Related reading
The default nobody questions
Every new SharePoint Online document library ships with versioning already enabled and a limit of 500 major versions — once a file passes that count, SharePoint quietly deletes the oldest version to make room for the newest. Most teams never touch this number, for better or worse: it’s generous enough that most files never hit it, but a handful of high-churn files (a shared tracker edited daily) genuinely can, and the deletion of the oldest version happens silently, with no warning before it occurs. Nobody gets an alert the day version 501 quietly pushes version 1 out of existence — it’s just gone, discoverable only by someone noticing the history is shorter than expected.
Intelligent Versioning: the current, better default
Worth knowing about specifically since it changes the “just accept 500 and move on” calculus above: Microsoft rolled out Intelligent Versioning (also called automatic version expiration) in 2024, and it’s a genuinely better default for most libraries, not just a storage-saving trick. Instead of a flat count, it uses an algorithm that keeps every version from the last 30 days, then progressively thins older versions out (weekly snapshots beyond 180 days, for instance) rather than deleting strictly by count. The real-world effect: meaningfully less storage consumed by version history — reductions of 90%+ over six months are commonly reported — while still preserving genuinely useful restore points across the file’s whole history, not just its most recent 500 edits.
Connect-SPOService -Url https://contoso-admin.sharepoint.com
# Turn on Intelligent Versioning for all NEW document libraries tenant-wide
Set-SPOTenant -EnableAutoExpirationVersionTrim $trueThe real gotcha, worth being deliberate about: this only changes the default for libraries created after the setting is applied. Existing libraries keep whatever version policy they already had — opting them in individually needs Set-SPOListVersionPolicy run against each one. A tenant with years of existing document libraries doesn’t get Intelligent Versioning’s storage savings automatically just by flipping the tenant setting; that’s a separate rollout decision, not a side effect of this one.
Intelligent Versioning only changes the default for new document libraries — existing ones keep their old policy until explicitly opted in with Set-SPOListVersionPolicy.
The real cost of approval workflows
Content approval sounds like pure upside — an extra quality gate before a version goes live — but it has a real, often-overlooked cost: every edit becomes a pending, unapproved minor version until someone actually approves it, and minor versions pile up the same way major ones do. A library with approval enabled and an inattentive approver doesn’t fail loudly; it just quietly accumulates a growing backlog of drafts nobody’s looking at, while the “live” version everyone sees keeps getting staler. Content approval is worth turning on deliberately, for libraries that genuinely need a review gate (a public-facing intranet page, a policy document) — not as a default “more control is always better” setting applied everywhere.
Major vs. minor versions: a policy decision, not just a checkbox
Turning on minor versions (drafts) is a genuine tradeoff, not a strictly-better setting: it gives editors a private working copy before anything goes live, at the cost of real complexity — co-authors need to understand draft vs. published state, and “why can’t I see the latest version” becomes a real support question the moment someone forgets they’re looking at the last published major version instead of an in-progress draft. Libraries where multiple people iterate before anything should be visible (a report being drafted collaboratively) benefit genuinely from minor versions; libraries where every save should just be visible immediately (a shared reference list, a simple tracker) are usually better off with major versions only — simpler for users, and no draft-state confusion to explain.
Auditing what libraries are actually set to
All three decisions above only matter if they’re actually being applied consistently — and since each is set per-library, not tenant-wide by default, drift is the norm rather than the exception once a tenant has more than a handful of libraries. Worth checking what’s actually configured before assuming policy and reality match:
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/YourSite" -Interactive
Get-PnPList | Select-Object Title, EnableVersioning, EnableMinorVersions, MajorVersionLimit, EnableModeration |
Format-Table -AutoSizeEnableModeration is content approval’s underlying property name — worth including in the audit specifically, since a library with it silently enabled and no one actively approving is exactly the quiet-backlog problem described above, and it’s easy to miss without deliberately checking for it across every library rather than just the ones someone remembers configuring.
Related reading
- Exploring SharePoint Files and List Item Versioning — the mechanics of how versioning actually works, including scripting it with PnP PowerShell.
- How to Delete File and List Versions in SharePoint — cleaning up existing version history, including measuring what it’s actually costing in storage.
- Extracting SharePoint File Version History Using PowerShell — recovering an old version’s actual content, not just its metadata.
- SharePoint Permissions: A Comprehensive Guide — who can actually approve content, if content approval is the right call for a given library.
By treating these as deliberate decisions rather than accepted defaults — what version limit actually fits, whether Intelligent Versioning is worth rolling out to existing libraries, whether approval is genuinely needed or just adding an unmonitored bottleneck, and whether the audit above matches what was actually intended — document versioning ends up doing what it’s meant to: real protection and traceability, without quietly becoming its own storage and complexity problem.
App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning