Applies to: SharePoint Online, Office for business, Office 365 Small Business, SharePoint Server 2019, SharePoint Server 2016, SharePoint Foundation 2013, SharePoint Server 2013 Enterprise, SharePoint Server 2010.
When versioning is set in your SharePoint list or library, you can store, track, and restore items in a list and files in a library anytime they change. Versioning, integrated with other settings, like checkout, offers you ample control of the content that is posted on your site and can deliver real value if you ever have a need to look at or restore an old version of an item or file.
Note: Versioning is on by default in SharePoint libraries, and off by default in SharePoint lists. For more info on setting up versioning, see Enable and configure versioning for a list or library.
Anyone with permission to manage lists can turn versioning on or off for a library. Versioning is available for list items in all default list types—including calendars, issue tracking lists, and custom lists. It is also available for all file types that can be stored in libraries, including Web Part pages. For more info on setting up and using versioning, see Enable and configure versioning for a list or library.
Note: If you are an Office 365 customer, versioning is now turned on by default when you create new OneDrive for Business libraries, and it will automatically save the last 500 versions of a document. This will help you prevent losing important documents or data. If you have existing libraries on your OneDrive for Business site or on your team site that do not have versioning enabled, you can turn versioning on for them at any time.
You can use versioning to:
- Track history of a version – Once versioning is enabled, you can review when an item or file was changed and who changed it. You can also see when properties (information about the file) were changed. For example, if someone changes the due date of a list item, that information appears in the version history. You can also see the comments people make when they check files into libraries.
- Restore a previous version – If you made an error in a current version, if the current version is corrupt, or if you simply prefer a previous version, you can overwrite the current version with a previous one. The restored version becomes the new current version.
- View a previous version – You can see a previous version without replacing your current version. If you are viewing version history within a Microsoft Office document, like a Word or Excel file, you can compare the two versions to ascertain what the variances are.
When versions are created
When versioning is enabled, versions are made in the following situations:
- When a list item or file is first made or when a file is uploaded.
Note: If file checkout is required, you must check the file in to create its first version.
- Once a file is uploaded that owns the same name as a current file.
- If the properties of a list item or file are altered.
- Once an Office document is opened and saved. After a document is opened again, a new version will be produced after an edit is saved.
- Frequently, when editing and saving Office documents. Not all edits and saves form new versions. When saving edits regularly, for example, each new version logs a point in time rather than each separate edit. This is frequent when autosave is enabled.
- Whilst co-authoring of a document, when a different user starts working on the document or when a user clicks save to upload changes to the library.
There can be a maximum of three current file versions at any specific time: the checked-out version, the latest minor or draft version, and the latest published or major version. All other versions are classified as historical versions. Some current versions are solely seen to users with viewing permissions.
Major and minor versions
Normally, a major version symbolises a milestone compared to a minor version which is a work in progress that and not ready for all site participants to read. Depending on your team’s style of working, your team may be inclined to have its most recent minor versions, like a version that was edited recently. Gradually, your team could be less likely to require an older minor version.
Some organisations track both major and minor versions of files in their libraries. Others only monitor the major versions. Major versions are recognised by whole numbers, such as 5.0; minor versions are classified by decimal numbers, like 5.1.
Most organisations use minor versions when files are under review, and major versions when particular milestones are achieved or once the files are ready for review by a large audience. The majority of organisations has draft security configured to enable only the file’s owner and people with approval permissions. Thus, minor versions are restricted for viewing by anyone else until a major version is published.
Major versions are available for lists, but minor versions are unavailable. Every version of a list item is numbered with a whole number. If your organisation mandates approval of items in a list, the items stay in Pending status until they are approved by someone with approval permissions. While in Pending status, they are numbered with decimal numbers and are labelled as drafts.
For more on enabling and setting up versioning, including major and minor versions, see Enable and configure versioning for a list or library.
Version numbers are instantly inserted each time you create a new version. In a list or library that has major versioning activated, the versions have whole numbers, like 1.0, 2.0, 3.0, and so on. In libraries, your administrator may enable versioning for both major and minor versions. Once minor versions are being tracked, they have decimal numbers including 1.1, 1.2, 1.3, and so on. When one of those versions is published as a major version, its number becomes 2.0. Forthcoming minor versions are numbered 2.1, 2.2, 2.3, and so on.
When you delete a checkout, the version number remains static. If the most recent version was version 3.0, it stays at 3.0 following you removing the checkout.
After you delete a version, the version moves to the Recycle Bin and its number follows it. The Version History will display the remaining version numbers. The other version numbers remain the same. For example, if you have a document that has minor versions 4.1 and 4.2, and you decide to delete version 4.1, the resulting version history shows only versions 4.0 and 4.2. The following picture shows this.
For more on enabling and setting up versioning, including major and minor versions, see Enable and configure versioning for a list or library.
Determining who can see draft items
You can manage who can view drafts of list items and files. Drafts are created in two scenarios:
- Once a minor version of a file is made or updated in a library that monitors major and minor versions.
- Once a list item or file is created or updated but still unapproved in a list or library in which content approval is mandatory.
When you track major and minor versions, you can confirm whether people must have permission to edit files before they can view and read a minor version. After this setting is customised, people with editing permission can work on the file, but those who have reading permission can simply read the file cannot see the minor version. If major and minor versions are being tracked and no one has published a major version yet, the file remains hidden from people without viewing permissions for draft items.
When content approval is needed, you can determine if files that are pending approval can be seen by people with reading, editing, or approval permission (including the author) to approve items. If both major and minor versions are being tracked, the author is required to publish a major version prior to submitting the file for approval. Once content approval is sought, people with with reading permission without viewing permission to see draft items will notice the last approved or major version of the file.
No matter whether or not people have editing permission, if people search for a file that is in minor version, they won’t find results for it.
Is there any limit to the number of available versions?
Some organisations permit unlimited versions of files and others apply restrictions. You might learn, after checking in the latest file version, that an old version is missing. If your most recent version is 26.0 and you realise that there is no longer a version 1.0, it means that the administrator programmed the library to allow a maximum of 25 major versions of a file. The creation of the 26th version leads to the first version to be deleted. Only versions 2.0 until 26.0 remain. Similarly, if a 27th version is added, only versions 3.0 until 27.0 remain.
The administrator can also decide to constrain the number of minor versions to only those for a precise number of the most recent versions. For example, if 25 major versions are allowed, the administrator might decide to keep minor drafts for only the most recent five major versions. The preset number of minor versions between major versions is 511. If you try to save another minor version, you will receive an error message that informs you that you must first publish the document. Your site administrator can edit the default to enable fewer minor versions.
If a list or library restricts the number of major versions, the earliest versions are erased when the limit is met. For example, if only 20 versions are retained, and your team creates 25 versions, only versions 6 through 25 are kept. If another version is created, only versions 7 through 26 are kept. If your list or library limits versions, you should ensure that contributors know that earlier versions will be deleted once the version limit is reached.
In a library that restricts the number of major versions that it keeps minor versions for, the minor versions are removed for the previous major versions once the version cap is reached. For example, if you retain drafts for only 10 major versions, and your team creates 15 major versions, only the major versions will be preserved for the earliest versions. The minor versions that are linked with the five earliest major versions — such as 1.2 or 2.3 — are deleted, but the major versions — 1, 2, and so on — are kept, unless your library also limits major versions.
Capping the number of versions is usually a good practice. It means you can optimise server space and minimise clutter for users. But, if your organisation must save all versions for legal or other reasons, don’t set any limits.
Important: If your organisation limits the number of versions that it stores, the oldest versions are permanently deleted when the limit is reached. They are not sent to the Recycle Bin.
For more on enabling and setting up versioning, including limits, see Enable and configure versioning for a list or library.
Notes: Both SharePoint Online and SharePoint Server, for both Library Settings and List Settings, allow up to 511 minor versions per major version. This number cannot be changed.
- Versioning – SharePoint Online requires versioning for Libraries; SharePoint Server allows you to select No Versioning as an option.
- Major versions – SharePoint Online Library Settings allows a range of 100-50000 major versions; SharePoint Server Library Settings allows a range of 1-50000 major versions.
- Minor versions – Both SharePoint Online and SharePoint Server Library Settings allow a range of 1-50000 major versions allowed to have minor versions.
- Versioning – Both SharePoint Online and SharePoint Server List Settings allow you to disable versioning.
- Major versions – Both SharePoint Online and SharePoint Server List Settings allow a range of 1-50000 major versions.
- Minor versions – Both SharePoint Online and SharePoint Server List Settings allow a range of 1-50000 major versions allowed to have minor versions.
Enabling/configuring, and using versioning in lists and libraries
Versioning is activated by default once a library is created rather than when a list is created. Anyone with managing permissions to can toggle on or off versioning. For most sites, that is the same person who administrates the site, since the lists and libraries assume permissions from the site. As wells as enabling versioning, the site owner (or another person managing the list or library) decides if they need content approval, who can view draft items, and if checkout is required. All of these decisions affects how versioning works. For example, if the person managing a library decides to require check-out, version numbers are only created when a file is checked in. If content approval is required, major version numbers are not applied until files are approved by someone who has permission to do so.
Important: If the people who work in your library are planning to co-author documents, do not configure the library to require check-out. People cannot work as co-authors once the documents that they need are checked out.
To learn how to turn on versioning for a list or library, see Enable and configure versioning for a list or library.
How does versioning work with required content approval?
If versioning is switched on in your library, the administrator influences whether to track both major and minor versions and also controls who can view the minor versions. Most of the time, once content approval is needed, only the owner of the file, and people with approval permission, can see the minor versions. In other libraries, anyone with editing permission can edit files in the library, or anyone with Read permission to the library, can check all versions. After a version is approved, everyone with a Read permission to the list or library can view the version.
Even though lists exclude major and minor versions, any item that is in Pending status is deemed a draft. In most cases, only the item’s creator and persons with Full Control or Design permissions can see drafts. A draft appears in Pending status for those people, but others merely notice the most recent Approved version in the version history. If the file is rejected, it remains in Pending status until someone who has the essential permissions deletes it.
Automatically, a pending item or file is seen only to its author and to the people with managing permission over lists, but you can elaborate if other groups of users can read the item or file. If your library is configured to track both major and minor versions, the person who edits the file has to start by publishing a major version of the file.
For more info on setting up approval for documents, see Require approval of items in a site list or library.
Note: Draft security, in some lists and libraries, is configured to allow all site users to see both Pending and Approved versions.
How does versioning work with file checkout?
Once you check out a file from a library that has versioning switched on, a new version is produced each time you check it back in. And, if major and minor versions are activated, you can decide, at check-in, which version type you are checking in. In libraries where checkout is required, versions are only formed upon check-in.
In libraries where checkout is optional, a new version is produced the first time you save after accessing the file. Every subsequent save updates the initial version that you created. If you exit the application and then reopen the document, the first save will, repeatedly, produce a version. This can result in the number of versions to multiply very quickly.
For more info on check in and out, see Check out, check in, or discard changes to files in a library.
Important: If you are co-authoring a document, do not check it out unless you have good reason to prevent others from working on the document.
Requiring check-out (Libraries only)
Requiring check-out can aid your team maximise versioning, because people specifically designate once a version is about to be made. A version is formed only when someone checks out a file, edits it, and then checks it back in. When check-out is not mandatory, a version is produced once someone first saves a file and this version is updated after the person closes it. If that person or someone else then opens and saves the file again, another version is made. Based on the situation, you may not want numerous multiple versions to be created, for example, if you must close a file to attend a meeting before you finish making changes to the file.
When check-out is required, people cannot insert files, change files, or change the file properties without first checking out the file. When people check in files, they are asked to give comments about the changes that they made, which helps to design a more meaningful version history.
Note: If the library will be storing Microsoft Project (.mpp) files that are synchronised with task lists on your site, the Require check-out box should be cleared.
For more info on requiring checkout, see Set up a library to require check-out of files.
List or library permissions
Lists and libraries have permissions connected to versioning and check-out that change depending on the permission level that is set to a user or a specific group. Someone who can edit permission levels can define these permissions differently or can design a new group with customised permission levels.
These permissions guaranteee flexibility with how you manage your library. For example, you may want someone to be able to delete versions of a file without having permission to delete the file itself. The permission to Delete Versions is different to the permission to Delete Items, so you can provide a tailored degree of control.
The following table presents the permissions that are associated to versioning and check-out and which default permission levels they relatey to.
|Permission||Default permission level|
|View Versions||Full Control, Design, Contribute, and Read|
|Delete Versions||Full Control, Design, and Contribute|
|Override Check-Out||Full Control and Design|
|Approve Items||Full Control and Design|
For more info on permissions, see Understanding permission levels in SharePoint.
Leave us a comment
Was this article helpful? If so, please let us know at the bottom of this page. If it wasn’t helpful, let us know what was confusing or missing. Please include your version of SharePoint, OS, and browser. We’ll use your feedback to double-check the facts, add info, and update this article.