Exploring SharePoint Files and List Item Versioning

SharePoint Document Versioning automatically saves iterations of a document as it changes, so you can see who changed what and restore an earlier version if something goes wrong.

In this post: Enabling versioning · Managing version history · List item versioning · Intelligent Versioning: automatic trimming · How many versions should you actually keep? · When would you actually use this?

Enabling versioning

Go to the document library where you want versioning.
Open Library Settings.
Under General Settings, select Versioning Settings.
Choose the type: No Versioning (only the latest copy is stored), Major Versions Only (1.0, 2.0 — for finalized documents), or Major and Minor Versions (1.0, 1.1, 1.2, 2.0 — for drafts and continuous updates).
Set how many versions to retain, to keep storage in check.
Save.

Managing version history

Right-click a document and select Version History to see past versions and what changed.
Select an older version and click Restore to revert to it.
Delete old versions manually, or let retention policy handle it automatically.

List item versioning — not just files

Versioning isn’t only a document library feature — SharePoint lists (task lists, custom lists, anything built on list columns) support the same major-version history independently. Turn it on the same way: List Settings > Versioning Settings > Create a version each time you edit an item in this list. This matters more than it sounds like it should, because list items don’t have a “file” to reopen and compare — version history is often the only record of who changed a status, a due date, or an approval field, and when. If you’re using a list to drive an approval workflow (a “Status” column a Power Automate flow watches, for example), turning this on gives you an audit trail of every status change, not just the current value.

Intelligent Versioning: automatic trimming

SharePoint Online libraries default to keeping up to 500 major versions per document — fine until a frequently-edited file actually hits that ceiling. Microsoft’s newer Automatic versioning mode handles this with time-based thinning instead of a hard cutoff: every version from the last 30 days is kept in full, then it steps down to one version per hour for 30-60 days old, one per day for 60-180 days, and one per week beyond that — all within the same 500-version cap. Microsoft’s own reporting shows this cutting version-history storage by up to 96% over six months compared to keeping everything until the limit forces deletions. It’s set per library (or tenant-wide as a default) alongside the regular versioning settings, and it’s worth turning on for any library where “who changed this three months ago” matters more than “every single edit from three months ago.”

How many versions should you actually keep?

5-10 versions for fast-changing documents like drafts and work-in-progress files.
25-50 versions for regulatory documents that need an audit trail.
Unlimited only for critical files with long-term compliance needs — contracts, legal documents.
Turn on auto-cleanup so old versions get dropped once the limit is hit, instead of storage growing unchecked.

The tradeoff is storage and performance — set a version limit that matches the actual retention need, not the default.

When would you actually use this?

Someone overwrote a document with the wrong content and you need what was there yesterday — version history is the fix, assuming versioning was already turned on.
You’re in a regulated industry and need to prove who changed a document and when — this is the audit trail, and it’s why compliance and governance policies usually mandate it.
A library’s storage is bloating and nobody knows why — uncapped versioning on a large, frequently-edited library is a common, invisible cause.
Multiple people are editing the same document and you need a clear record of who changed what, without anyone’s work silently overwriting someone else’s.

The tradeoff is storage and performance — large libraries with unlimited versioning and no cleanup policy will eventually feel it. Set a version limit that matches the actual retention need, not the default.

That should do it. Let me know in the comments if something’s not working for you.