…there is for sure some room for improvement, but before we get to that, you may need a quick primer on how standard features of SharePoint versioning and content approval work.

If you are across this already then please feel free to jump to my next article where I identify scenarios in which we need something better and then in the 3rd part in this series, I will walk you through a solution we built to explicitly address these short falls.

How Major and Minor Versioning Works

Version control is enabled on SharePoint libraries by default, but it is configured to be major versions only. This means that every time a document (or even a single metadata attribute) is updated, the version number, automatically maintained by SharePoint is incremented by an integer whole number, so the versions progress as 1.0, 2.0, 3.0…

However, from Library Settings > Version Settings, you can change a library (not a list – this setting is available to document libraries only) so that it supports major and minor version as shown below:

With minor versioning enabled, a newly created or added document will be assigned the version number 0.1.

Updates to this document now bumps the minor version number to 0.2, 0.3, 0.4 … Note, that to see the Version column you will need to add it to a view as it is not shown by default.

If you want to push a document to its first major version, you must physically take action to publish it by selecting it the list view and clicking the Publish Button as highlighted below:

This will pop-up the Publish Dialog, where you can add some comments, if you feel so inclined.

You can also access this dialog from the document item menu, which is called the Edit Control Block (ECB) menu for historical reasons, by clicking on the ellipsis (those 3 dots) and selecting More > Publish.

But this is way more cumbersome than using the menu bar.

Note that documents can only be published one at a time. This is a pain sometimes but something that you just need to suck up! I suppose the logic is that you would likely want to assign unique comments to each document, but SharePoint does support balk approvals (which we will come to in the next section) and they too have the options for comments and so we have some inconsistency here.

Once you publish a document for the first time it will sit at version 1.0.

When a document is at a major version, the Publish/Republish button is not shown in the command bar, which makes sense because at this point the document doesn’t need publishing, it is published!

If you have jumped the gun and published a document too soon, you can reverse the action from the ECB menu … > More > Unpublish. This option is not available from the command bar.

Any subsequent edits to the document will bump the minor version to 1.1, 1.2, 1.3…

Note that after the initial publish to version 1.0, the UI changes so that the command bar button and the ECB menu item now say Republish rather than Publish. I nice touch, I guess so that you can tell at a glance the document already has a published version.

In many cases this just major/minor versioning just causes friction, and I have seen many a library with minor versioning enabled, where nobody ever publishes document as a major versions, so you see them with a version number that is below zero such as 0.21.

Yes, but what’s the point of this?

You might now be asking yourself (quite reasonably I feel), what the point of this is. Doesn’t this just add friction to the process of managing documents? And, to make matters worse, by default minor versions are not indexed by the search engine and so users might get confused as to why a document shows in the UI but not in search results.

If this library is to be used solely for collaborative working, where users are editors rather than simply consumers I would agree, you don’t need minor versioning enabled as it will just get in the way.

However, if the library is primary aimed at providing access to consuming users as managed reference documents, and documents are updated by a subset of subject matter experts, minor versioning makes more sense. Let me show you the magic source that you may be missing.

If you go back to Library Settings > Version Settings, there is a section on this page called Draft Item Security. By default, this is set to Any user who can read items but if you consider changing it to one of the other two settings, the reason for enabling minor versioning starts to make more sense.

What this means is that SharePoint will behave differently based on the permissions the user has on the document.

With the above setting, users with read-only permissions get to see major versions only. This allows Editors (those with read/write permissions) can work on the minor versions (the drafts) between major versions in the knowledge that consumers only get to view the latest major version. In other words, publishing a document as a major version is effectively a formal release mechanism for those users with read-only permissions.

This works for new documents as well, in that until a document is published for the first time, read-only users don’t even know that it exists as a draft. Not only does it no show for them in the search engine but it doesn’t show if the browse the library directly either.

This can be particularly useful for important Controlled Documents (Policy, Procedure etc.) which might be linked or otherwise surfaced on say the corporate Intranet, we don’t need to make any changes to those links because publishing the document as major version does not change the URL and so consuming users can be assured of accessing the latest approved major version of the document without making changes anywhere else in the wider system. Now do you get it?

Content Approval

We can take this idea to the next level by activating Content Approval, again from Library Settings > Version Settings.

Incidentally, unlike Major/Minor Versioning, Content Approval can be enabled for both Lists and libraries alike.

When enabled, together with major/minor versioning, what happens now is that an extra step gets added into the process and to support this an extra system managed column in the library called Approval Status.

Now what happens is that a document in a draft state (i.e. when it has a minor version) cannot be published as a major version directly, but rather it is submitted (by an editor) for approval, see below:

When a user clicks the Submit for approval button, they are presented with a Publish Dialog again and although dialog button still says “Publish” the document will remain as the same minor version, but its Approval Status value is updated to Pending.

This is a signal for someone with Approval Permissions (see next section) to review and approve the request for publishing as the next major version, or to reject the submission.

This means that when Content Approval is enabled, every documents must be in one (and only one) of 4 states:

• Approved: The document is sitting as a published and approved major version.
• Draft: The document is at a minor version but has not yet been submitted for approval.
• Pending: The document is at a minor version but has been submitted for approval, but no one with Approval Permissions has yet acted to approve or reject the submission.
• Rejected: The request to publish the document as a major version has been rejected and so remains at a minor version.

When a document with a rejected submission is updated subsequently, it will revert to Draft status and can later be resubmitted for approval.

When a document is in the Pending state, an approver will see the Approve/Reject menu item in the command bar, although they may need to go look for it in the overflow ellipsis

Or you can access the same function from the ECB menu … More> Approve/Reject

Either route will result in the popping up the Approve/Reject Dialog where the approver can optionally add comments and indicate their decision.

If a document is approved, it will transition to the next major version, and the status will change to Approved.

An approver can reverse their decision (or the decision of another approver) and unpublish a document from the ECB menu.

In which case, the document will revert its previous Draft state where it can be worked on and resubmitted for approval subsequently.

Is Content Approval a good idea?

Well that depends. By enabling Content Approval, we have added more friction to our document management process for sure. Even if you have approval permissions you can’t publish and approve a document in a single action, you must first submit the document for publishing and then explicitly approve it as a separate subsequent step.

This may seem strange, because if I submit a document for publishing I obviously intend for that submission to be approved and if I have approval permissions, I am effectively approving my own work! Strange as it may seem, that’s just the way it works.

And yes, it does add friction to the process, but that is entirely the point. Think of Content Approval as being a quick final quality control check made by someone with higher permissions than editors.

In many cases, this is just fine but, as I pick up in my next article, this simple 2-step process is often not sufficient. In some cases, organisations want a multi-step approval process – that want more friction!

Content Approval Permissions

We have so far skirted around the issue of how we assign approval permissions to select users, and this is obviously an important step as these permission are not assigned to Site Members by default, as you would expect, otherwise everyone would simply approve their own work, as described in the previous section.

Site owners and admins have full control over the site (and so the library by default) and that includes the permissions to approve documents.

However, we probably don’t want our approvers to have full control of the site and so a better approach will require a little configuration.

Every SharePoint site is provisioned with 5 standard Permission Levels.

And 3 standard SharePoint Groups:

Looking at the above screenshots you can see there is a mapping between Permission Levels and Site Groups in that Owners get full control, Members get edit-level permission and Vistors get read only access.

The Permission Levels, Design and Contribute are not used (by default). By the Design Permission Level is the one that is useful to us here, because it includes the permissions to approve items and documents.

So an easy way to set things is to:

• Create a new SharePoint Group – let’s call it Document Approvers
• Assign this group to the Design Permission Level
• Add our approving users to this new SharePoint group.

Note that setting up a new group must be done by a site owner or administrator, but ownership of the group can be assigned to any user, (Dame Edna in my case below) and the group owner can control group membership

The site will now have (at least) 4 SharePoint Groups with our new one being assigned to the Design Permission Level.

Don’t forget to add the appropriate users to the new group

Because we have set these permissions at the site level, they will be passed down to all lists and libraries in the site have set to inherit site permissions, which is the default position.

This may or may not be what you want. It might be that you need different permissions or different lists and libraries and that is entirely possible – but you must set unique permissions at the list/library level to set this up.

Whilst it is possible to assign users direct permissions either at the site or at an individual list/library, this is generally not considered a good idea as it become difficult to manage.

Best practice is to:

• Create SharePoint Groups
• Assign these groups an appropriate Permission Level
• Add users and (better still) AD Groups to these SharePoint Groups
• Grant permissions to these groups on the appropriate securable containers (lists/libraries, folders or document sets) within the site.

In Summary

SharePoint natively provides some very useful tools that might be used to enhance your document management processes.

Although Major/Minor Versioning and Content Approval are not required in many situations (I wouldn’t generally recommend enabling these features in team collaboration site for example), there are occasions when the services are invaluable, especially when you need to segregate consumers from editors so that you can implement a more rigorous version approval and release process.

As good as these feature are, for many organisations and scenarios they don’t offer enough flexibility, nor do they provide governance tools which can be used to monitor when documents should next be reviewed and more.

In my next article, I will describe what I think is missing from the standard arsenal that SharePoint offers which leads up yet another post which describes a solution we have built at Kaboodle Software which seeks to address these shortfall.