SharePoint versioning settings: keep drafts private without blocking coauthoring

A SharePoint document library can let editors work together while readers continue to see an approved version of a document. Set the library’s version type, draft visibility, approval, and checkout for that workflow. Version history limits are a separate choice: they control how much older history the library keeps.

Choose the library’s workflow

For a shared working library where each saved release can be public to its readers, major versions with required checkout off is a practical configuration. Editors can work together without reserving a file for one person.

For a staff policy library where proposals must stay out of readers’ view, choose major and minor versions and set draft visibility for the people who should review drafts. Turn on content approval if a designated owner must approve publication. Keep required checkout off when editors need to coauthor. Microsoft’s SharePoint Server planning guidance describes checkout as exclusive editing and advises against combining checkout with coauthoring. Microsoft versioning and checkout planning

Draft visibility does not give someone new permission to a file. It determines which people who already have appropriate access can see draft versions. A library owner should decide who may edit, who may review drafts, and who should read published material before setting it. Microsoft: How versioning works

Set the options in one library

Open the intended document library, then go to Settings > Library Settings > Versioning settings. There, choose major versions or major and minor versions, set content approval and draft visibility as needed, select the version limits, and decide whether checkout is required. Select OK to save the library settings. These steps apply to the selected library, so confirm its name before making the change. Microsoft: Enable and configure versioning

Microsoft says new Microsoft 365 lists and libraries have versioning enabled automatically. That does not establish the settings or history of an older library. Open its versioning settings to see the policy you are actually configuring. Microsoft: How versioning works

See what an editor and reader would see

Consider a fictional Staff-policy.docx. On Monday, approved version 3.0 states a $50 limit. On Tuesday, an editor saves draft 3.1 proposing a $60 limit. A reader without draft visibility still reads the approved $50 policy. The editor and reviewer can work on the proposal.

When the author submits the revised policy for publication and approval, it enters the approval process. A reader who cannot see drafts continues to read the previous approved version while the proposal is pending. After the next major version is approved, the reader sees version 4.0 and its $60 limit. The illustration separates saving a draft from approving its publication. Microsoft: How versioning works, Microsoft versioning and approval planning

If the editor sees the proposal while the reader still sees the $50 policy, first check draft visibility and approval status. That matches the intended publication state if draft access is restricted and the new version has not been approved.

Set a history limit with both rules in mind

SharePoint supports automatic and manual version history limits. Automatic limits keep more recent history densely and thin older history. A manual policy can use a major-version count alone or a count together with an expiration period. For a manual policy, a historical version can fall outside the policy because it exceeds the count or because it is older than the age limit. A count alone therefore does not promise a fixed number of days of coverage. Microsoft: Plan version storage, Microsoft: Document library version history limits

The documented manual controls have minimums of 100 major versions and 30 days in the user interface. An example such as 20 versions for seven days would not be a valid UI configuration. For historical versions, the age calculation relates to the version’s snapshot date, not the document’s original creation date. An organization can set a default for new libraries, while a site or individual library can have its own policy. Microsoft: Document library version history limits

Work through a 500 version, 365 day example

The synthetic manual limit worksheet uses a hypothetical limit of 500 historical major versions and 365 days. “Rank” means a major version’s position in an already ordered historical major-version list, not the version number displayed in SharePoint. In this simplified whole-day calculation, a rank above 500 fails the count rule and an age above 365 days fails the age rule.

Historical major-version rank	Age in days	Illustrative result	Reason
500	365	Within both limits	Neither boundary is exceeded
501	12	Outside limit	Count is exceeded
30	366	Outside limit	Age is exceeded
501	366	Outside limit	Both are exceeded

Minor drafts have separate limits; this example counts only historical major versions. The worksheet is an arithmetic example, not a SharePoint export or a prediction that a particular version will be deleted. Actual age processing depends on the version’s expiration timestamp. Items under a retention policy or an eDiscovery hold are exempt from library version limits while that protection applies. Microsoft: Document library version history limits

Account for changes to an existing policy

Changing a library’s age limit applies to newly created versions; it does not assign a new expiration to every old version. Lowering its count can trim existing history gradually as files are updated, by up to 20 old versions per new version. Thus, a newly configured limit and the versions currently present in a file’s history can differ. Microsoft: Library version limits

A site-level policy change has another timing consideration. Site-level settings are managed through PowerShell, and an update to existing libraries can take up to 24 hours. Changing the site policy itself does not trim existing history. If a library does not yet show the expected site policy, allow for that update window and check whether the library has its own setting. Microsoft: Site version limits

A separate batch trim is a permanent removal operation that bypasses the recycle bin. Microsoft documents an impact report and what-if step to assess it before committing. It is distinct from choosing an editorial workflow or setting a library policy. Microsoft: Trim versions

Inspect the configured policy

After an authorized SharePoint administrator has connected to the tenant, this read-only command can inspect one library’s configured version policy. Replace each placeholder with the intended site and library:

$siteUrl = "https://YOUR-TENANT.sharepoint.com/sites/YOUR-SITE"
$libName = "YOUR-LIBRARY"
Get-SPOListVersionPolicy -Site $siteUrl -List $libName

The result describes the configured policy. It does not prove how many historical versions a particular file currently has or how far back its accessible history extends. Microsoft: Library version limits

Check the symptom in the right place

If Library Settings is unavailable, ask the library owner or someone with comparable management permissions to inspect the configuration. If editors cannot work on a document together, check whether required checkout is on. If an editor sees a new draft but a reader sees the older text, check draft visibility and approval before changing access.

For a missing earlier revision, open the file’s ellipsis menu > Version history; More may be needed to reach it. A revision might not have been captured, might no longer be retained, or might not be accessible to the person looking. If the required earlier version is present, use its date menu and select Restore. SharePoint adds the restored content as a new version. Microsoft: Enable and configure versioning

The steps follow Microsoft documentation. The downloadable worksheet is a synthetic arithmetic example, not an export from a SharePoint library.