By Cathy Dew
In the first part of this blog post, we talked about the basics of the SharePoint document versioning feature. From how to enable versioning to the difference between major and minor versioning, all the way to the benefits of the file check-in and check-out process, we looked at everything you need to get started with versioning in SharePoint.
Once your team is up and running with versioning, though, there are a few things you will want to know to help you get the most out of this feature. In this post, we will look at some of the more “advanced” features of document versioning in SharePoint, including usage limitations, version history, and collaborative authoring.
Understanding the Usage Limitations of Version History
In the first blog post, we discussed at length the benefits of SharePoint version history. Having the opportunity to revert to an older version of a file can be hugely beneficial if someone accidentally deletes information from the file during an edit. For data recovery, audit trailing, and overall peace of mind, having a backup in the form of version history is essential for important files.
Of course, versioning also has its drawbacks—namely the impact file versions can have on your storage space. Every file version—major or minor—takes up roughly the same amount of space as the original file. When your team gets started with versioning, storage space probably won’t be the first thing on anyone’s mind. After all, by default, SharePoint’s document libraries can support approximately 30 million documents. With so much storage space, is there indeed any risk of running out of space?
There are two things wrong with this line of reasoning.
First, just because you have space to work with doesn’t mean you should use it without consideration. Versions can add up quickly. Say you opt to create and save a minor version every time someone edits a file, or that you have three or four major versions on average per document. Multiply those numbers across a library of a few thousand files, and you can start to see how much space they are going to occupy.
If you are using an on-premise server, this kind of space usage is reckless. Server space is expensive and challenging to maintain. Furthermore, having extra server storage usually means having additional physical space to store the server components. Most enterprises don’t have much extra space in their server rooms. To avoid a costly, logistical challenge, you should be making the most of your server space. That means not wasting it on file versions that are almost identical.
If you are using a SharePoint Online installation, you still can’t use storage space haphazardly. Microsoft is generous with the storage limits it sets for SharePoint Online clients, but that doesn’t mean you have infinite space. Microsoft is a business, serving many different clients, always working to turn a profit. In other words, Microsoft is not going to give you infinite storage space to play with. Every SharePoint library, therefore, has limitations that enterprises should be aware of when it comes to storage capacity.
The usage limits of SharePoint represent the second reason that your team needs to be conscious of how many file versions are stored in any given list or library. Every document library or list has several usage limits that you need to follow. We already mentioned the limit of 30 million documents per library. Microsoft also restricts the file size you can upload (50 megabytes by default, though an administrator, can increase it up to two gigabytes), among other things.
Microsoft also restricts the use of versioning for your lists and libraries (though the average enterprise will never even approach these limits). For each file in your SharePoint list or library, SharePoint permits you to have up to 400,000 major versions. Each major version can have up to 511 minor versions. Those numbers are massive, and there are very few scenarios in which any SharePoint team will need to use them. SharePoint admins can also lower these numbers to control version use. If you choose to set limits different than the defaults, just tell your team. When SharePoint does reach its version limits, it automatically starts deleting the oldest versions—something that can potentially cause problems if your end-users aren’t aware of it.
Viewing Version History
If your team does somehow approach SharePoint document versioning usage limits, you will start running into technical difficulties. According to Microsoft, problems include not being able to open, save, or delete files. You will also probably have trouble viewing the version history of the documents with many versions.
Naturally, all these things are problematic. Not being able to view your version history defeats the purpose of having one in the first place. With versioning enabled, SharePoint adds a new minor version of a document every time you save, every time you check a file back in after checking it out, and every time you overwrite an existing document. If you are using co-authoring, SharePoint automatically creates a version at 30-minute intervals every time someone from your team edits a document.
This kind of system can seem excessive at first. Why would you need so many versions of a file? What this system guarantees, though, is that you always have a recent backup of the file you are working on. If you accidentally save over your file, there is probably a recent version that you can use to recover most of your work. The same is true if your computer crashes when you are working on a file. With version history, you will seldom lose more than a few minutes of work—let alone a complete file.
To use version history, you may have to enable it first. Microsoft enables version history by default on all new document libraries in SharePoint Online. In older versions of SharePoint, though, you may have to enable it manually. To check and see if version history is active in your files, navigate to the file you want to view version history for and click the ellipsis new to the file name. A hover menu will appear on your screen. Click the ellipsis in the hover menu and then select version history from the dropdown menu.
If version history is enabled, you should now be able to see all the various versions of the file in question. Including the actual versions of the file, the version history pane should also include details about each adaptation. These details include the version number, date, and time stamps for when each version was created, the name of the person who created each version, and the size of the file. There is also a comments field, where the person who edited the file can summarize the changes they made. The comment field is especially useful in a collaborative environment, as it doesn’t leave team members guessing about what has changed from one version of the file to the next.
Collaborative Authoring and Content Approval
SharePoint’s versioning feature is compatible with the collaborative environment of many companies. Versioning makes it easy to monitor who makes what changes and to allow multiple people to edit a file without overwriting the previous version. However, the traditional versioning system—in which a user checks out a file, makes changes, and then check it back in—is not a true co-authoring environment. SharePoint also allows co-authorship, where two or more users can access and edit a file simultaneously.
As mentioned previously, SharePoint notes when a co-authoring session is active and changes the way it creates versions. Because a team of co-authors might work on a single file for several hours, it’s safer for SharePoint to create an updated version every half hour than to rely on the users to save regularly. This extra versioning backup step is also necessary since true co-authoring is not compatible with SharePoint’s check-out/check-in feature.
Co-authoring is compatible content approval. A team can go in and work on a file together, but their revisions can still be within the purview of an approver to review and approve. In this kind of scenario, each person’s revisions would save as a separate draft. The first person would save their changes, which would be cataloged in a pending minor (or draft) version of the file. The same thing will happen when the second person makes changes, and then the third person. The approver would have to review the drafts and determine whether they should be published as major versions.
This kind of content approval is also possible for any versioning—not just in a co-authoring environment. To enable content approval for versioning in your document library, navigate to “Library Settings” and choose “Versioning” under General Settings. Under “Require content approval for submitted items,” you would select “Yes.” Under “Create a version each time you edit a file in this library,” you would choose “Create major and minor (draft) versions.” Just like that, you’ve enabled content approval for your version history.
Consult with 2Plus2 Today
Do you need help figuring out versioning, version history, co-authoring, and content approval for your SharePoint document library? If so, 2Plus2 can help. Go online to schedule a free consultation with our team or call 510-652-7700 today.
Sources: