We’ve all dealt with it before. You’re working on an important document with several people. A few edit the document and email their copies to the team and in the exchange, some changes are lost or overwritten. Now the editors need to work together to make sure that their changes are reflected in the latest version of the document. If you’re working with a small document, it’s a nuisance to correct and you may not have an issue finding the mistakes. If you’re working on a 10, 15, 20+ page document, corrections become a larger challenge and you need to figure out how to piece together the correct information to form the one version of the truth.
One common workaround that people tend to use is renaming the file and slapping version numbers to the end of the filename. SuperSecret-v1.docx and SuperSecretPresentation-v1.pptx. This approach sort of solves their problems unless someone doesn’t make the changes to the correct file. Maybe they get left out of the email that included SuperSecret-v2.docx and they made an update to SuperSecret-v1.docx. Maybe 2 people are working on v1 and both rename it to v2 and start sending emails with both copies of v2. You are now back where you started reconciling the changes. 6 months down the road, someone decides to look up that document in their email and they’re sifting through emails to make sure they have the right document.
There needs to be a better way and with SharePoint, there is. Using the Version Control settings that are available in SharePoint libraries, you can specify how you’d like to version your documents and whether you need approvals on those documents. I have a sample Sales library which I configured to use major version, meaning that I want the documents to be versioned 1.0, 2.0, 3.0. Doing it this way will result in anyone with access to the document to see the latest changes once they are published. If I choose to use minor versions, SharePoint will keep track of incremental changes made (version 1.1, 1.2, 1.3, 2.0). Each save will increment the number after the decimal point until a major version is published and then everyone will be able to see the major version. In other words, only those with the ability to edit the document will see draft versions like 1.1 and 1.2, but everyone with read access to the file will only see the published versions like 1.0, 2.0, etc.
In the library settings (or list settings), you can configure the version settings to meet your needs. The following screenshot shows the version settings page.
Based on the configuration in the screenshot, my site is now setup to handle multiple versions and I have decided that I only want to keep the last 5 changes made to any document that is stored in that library. If I go back to my library and select my document, I can see who modified the account and a preview of the file on the right so that I know I’m looking at the correct, super-secret document. You can tell by the preview that all I have are section headings and no content in each section. I can also see who has access, and the recent activity.
We now have a library that is configured to use basic versioning. At this point, there is no more reason for there to be any confusion about whether you are working with the latest document and if everyone’s changes have been incorporated. Let’s see how.
I’ve uploaded the document that, as I mentioned earlier, only has section headings and no content. Adele is given a link to the library and makes several changes. Anyone viewing the document will immediately have access to the latest changes. SharePoint will keep a version history based on our settings and we can restore the past versions available to us, if necessary.
We’ve gone through some of the basics of version control in SharePoint. I encourage you to try different options like enabling minor versions, checkout, and co-authoring. (Co-authoring allows multiple people to edit a document simultaneously and see each other’s changes as they are happening). Save time editing documents by ensuring that your team is working with files stored in a single location.
SharePoint/Office 365 Architect
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
|cookielawinfo-checbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.