In my previous post I provided a walkthrough on how to configure SharePoint document libraries to support Major and Minor Versioning and Content Approval and took some time to outline scenarios in which these features of SharePoint might be useful.

My main conclusion was that if you are using SharePoint to manage documents in a collaborative work space such as a Team Site (or the SharePoint Site that sites behind every MS Teams Site) then you probably don’t need to worry about these features.

However, in scenarios where the library is providing key reference documents for consuming users, enabling these features and configuring them correctly will enable editors and approvers to work together on document updates in the background, as it were, without affecting what consumers see. This is because SharePoint libraries can be configured so that users with read-only permissions have access to the latest major document version only. Any minor versions are hidden from them.

In a previous article I explained the 3 bucket for document management which recognises that every document held by an organisation can be classified as either:

• Controlled Document: Documents such as policies, procedures, SOPs etc, which are used to govern business processes.
• Transaction Documents: Documents generated as a result of executing business processes, which collectively will provide a record of that transaction, hence this type of document is commonly referred to a record.
• Transient Documents: Documents which oil the wheels of business processes (such a most email) but has no long-term value to the organisation and so should be disposed of when they are no longer relevant.

If you haven’t read this post, I recommend that you find the time to do so – it is a thoroughly good read!

It is my assertion that when Transaction documents (records) are created and managed within SharePoint, the standard features of a library (without major/minor versioning or content approval) are generally sufficient.

There may be some exceptions to this. For example, if my process involves generating a proposal or quote for a client, it might be useful to set some controls for review and approval before said documents get dispatched, but mostly, enabling these features just adds friction and slows things down, for little or no gain.

Transient documents don’t need to be in SharePoint at all. They can stay in email boxes or chat threads. If an email (or chat message for that matter) does contain information that is of significance to the record, then it should be stored in SharePoint along with the other relevant records, as a record is a record regardless of its format or delivery media.

When it comes to Controlled Documents however, these approval and release features might prove invaluable as they potentially provide a way to establish a well-managed and properly governed system that keeps consumers happy, let information managers sleep easy at night and have auditors singing your praises!

The only problem is…

When setting up a tight governance system, these features on their own, don’t go far enough in giving most organisations what they truly need. Major/minor versioning and content approval puts us on the right path but sadly doesn’t quite cut the mustard for some scenarios in the real world (that could be the epitaph for SharePoint as a whole I guess).

There are a number of shortcomings which I will outline in this post. And then in my next post I will go on to describe a solution we built at Kaboodle Software called K-Docs Approve, which neatly slots into SharePoint and adds the missing capability that standard SharePoint lacks to support more complex approval processes.

Not enough steps in the process

The standard solution provides a single, or 2-step approval process only.

With major/minor versioning, editors can control what consumers see by keeping behind-the-scenes revisions hidden and only publishing documents as major version when they are ready to be shared with consumers. This is a single-step approval process where all decisions, content and quality control are the hands of editors.

When we enable content approval, we can turn this into a 2-step process. Editors submit documents for publishing as a major version, but they won’t be published until an Approver gives the green light to the submission.

By helping organisations set up a site/library to manage their Controlled Documents, I have learned that in many cases either a 3-step or sometimes a 4-step process is required.

In such a system, each step would be assigned to a role, which amount to a “hat” that a user wears when working within the system. Typically we see 5 roles in a 4 step process.

Let’s look at the roles first – we need:

• Editors: Subject Matter Experts (SME) tasked with creating new products or updating existing ones.
• Content Reviewers: Also SMEs, they might be a co-worker of the Editor or their line manager. Their main task is to review the work done by Editors to ensure it is fit for purpose.
• Quality Controllers: Tasked with ensuring the document meets organisational standards for spelling, grammar, style, tone, layout, fonts, graphics and the like. Quality Controllers are not usually SMEs.
• Approvers: Users who formally, authorise the release of authoritative product versions for consumers. Approvers are likely to be senior managers and will have some domain knowledge relevant to the document, but they are not necessary SMEs.
• Administrators: Users who manage the system as a whole by ensuing the library is appropriately configured and that users have the appropriate permissions needed to fulfil their role (Editors, Content Reviewers and Quality Controllers need read/write permission only, but Approvers will need approval permissions in addition.

From these roles we can envisage a 4 step process in which:

• Editors send documents to Content Reviewer when they think their work is ready.
• Content Reviewers either accept the work of Editors (possibly after making a few minor tweaks themselves) and send it on to Quality Controllers, or the reject the submission and send it back for reworking.
• Quality Controllers review documents submitted to them by Content Reviewer which they either accept it and send it on to the Approvers, or they reject it and send it back to either the Content Reviewer or the Editor.
• An Approver will review the product submitted from the Quality Controller and will either accept it, in which case it will become the latest approver major version, or reject it back to Quality Controller, Content Reviewer or Editor as they see fit.

If we now consider this as the lifecycle for the management of our controlled document, it might look like this:

Please read my primer article if you want to consider what might trigger an approval cycle.

Some organisations, especially smaller ones, we might not need so many steps and roles. It would be entirely possible to fuse Content Review and Quality Control into a single step/roles, assuming that the person tasked with content review also has the knowledge and expertise required for quality control.

You might also consider rolling the first 3 steps into as single step/role. In this case we are back to where we were with a 2-step process where the Editor is also the Content Reviewer and Quality Controller. But the assertion I am making here is that for an organisation of any appreciable size (say 50 or more employees) at least a 3-step process is necessary and quite possibly all 4 steps might be required.

Any solution that we might develop to support this scenario would need to be flexible enough to support a 2, 3 or 4-step approval process, but more about K-Docs Approve in my next post.

Where’s the workflow?

Another failing of the standard SharePoint OOTB offering is that it simply set status flags and assigned access restrictions in the process. This standard system has no sense of who might be assigned to one of the roles we identified in the previous section, because those roles don’t exist in SharePoint and so nothing happens when work progresses. It relies on a mechanism outside of the system to inform stakeholders when they need to do something. This usually means that Editors send an email to an Approver to let them know that their work is ready for review.

The typical reaction to this lack of automation is to use the tools that Microsoft provide to build the workflow as you need it. Crack open Power Automate (PA) and craft a custom workflow solution.

PA is a fabulous and amazing piece of software engineering, for sure, and I’m a great fan. But, despite it being pitched as a tool for end users (there are hooks all over the SharePoint UI that encourage users to embrace the faith), the reality is that it is beyond the skill set of most citizen developers to build something like what is needed here.

Superficially, our process might look simply, but the reality of trying to build a robust PA workflow puts it far beyond the reaches of the amateur. Take a look at the rejection paths in the above diagram and it becomes obvious that a PA workflow would soon deteriorate into a spaghetti mess of pathways to allow users to send work back to a previous step. This is because PA is essentially an application for building sequential workflows. It’s ideal when there is a clear and simple linear flow from trigger to result where there are very few exceptions that need to be mapped out.

Sadly, this doesn’t fit the mould when it comes to document reviews and updated. Collaborative working is messy with document statuses often bouncing all over the place before an approved release can be settled upon. Rejections, refinements and reworking are not exceptions they are the norm!

Using a sequential workflow to manage an approval process can be done – just, but the more steps you need, the number of exceptions you need to create a route for grows exponentially. I would say that a 4-step process is about as complex as you can make it before the flow becomes too unwieldy making it difficult to difficult to manage and all but unfathomable except to the person who constructed it.

For these messy collaboration scenarios, what need a different type of workflow, called a state machine. In a state machine, the current state is determined by reading the values in environmental variables. When something changes in the machine, these variables may be updated, and the current state may change as a consequence. This approach makes things hugely simpler for processes which need to bob about – like document approvals.

Sadly, PA doesn’t natively support state machine workflows. You can build a state machine in PA and common approach is to have a master workflow which triggers mini child workflows. But this means that we might end up with half a dozen workflows that all need to be managed, monitored and paid for!

And it gets worse! Image you now need a similar (but not identical workflow) on other libraries in other sites. That makes takes a great deal of work and results in a considerable management overhead.

Notifications?

The standard OOTB solution does not even send a notification message to Approvers when a submission for publishing has been made. I think this is decision to avoid spamming approvers, who are busy people, no doubt and who might complain, or simply ignore auto-generated notifications if there are too many of them.

Of course notifications might be handled by the workflows, but you can’t just send out arbitrary emails when some event triggers a state change. No, these emails need to be targeted to just the relevant stakeholders in each specific approval process instance. This can still be done on PA but now our workflow has become even more complex as it will need to be able to identify which users are assigned to which role in each workflow instance. More complexity: no wonder Microsoft didn’t want to take this on as feature of SharePoint!

And what about status tracking

Its not good enough to manage the processes in flight, we need a system that is going to track when a document is due for review and we want to be able to get key visual indicators (something like a traffic light system) so we can tell at a glance when documents are in-date, coming up for review, or are overdue.

We can build such features into a SharePoint library, simply by adding a Next Review date column and setting that property manually. But here’s the rub, You’d need to set the next review date value manually before the document was approved and published as a major version. If you set the value after the document was published, it will create a new minor version of the document and it is not what we want, we want to see all our published, approved documents, sitting at a major version number and not as a minor version between majors, or else how can we tell what documents are currently in a true revision cycle?

Admin quick publish

This last point highlights another thing that’s missing with SharePoint OOTB and that’s the ability to do a quick admin publish without initiating another workflow approval cycle.

Take the scenario, where a document has just been formally released by an Approver and then someone spots a typo or some other minor correction that needs to be made (it happens). With the standard toolset we’d need to edit the document (and so set it back to draft) and then resubmit it as pending and then get an Approver to approve it again – and that’s just with a 2-step process! It would become even more protracted the 4-step process I am advocating – all for the sake of a missing comma!

Ideally, we’d want is to make the minor correction and have a way to push a document straight to being an approved major version again, without the need to involve the unnecessary engagement of other stakeholders.

Of course, we wouldn’t want everyone to have this capability – it might be too tempting for overzealous editors to side-step the formal process. However, it would be really useful to be empower users in the Administrator so that they can do this, when the need arises (and it will arise I assure you).

Don’t jerk me around!

The final thing I want from a ‘ideal’ approval system is that I’d like to be able to do everything from one place, and that place should be SharePoint, where the documents are hosted. I don’t want to be jerked around between different apps that have a decidedly different look and feel.

Basically, I want to be able to manage everything in a single solution that looks and feels as though it is a natural part of the SharePoint UX – I want it to be embedded so I don’t need to deal with multiple apps and their idiosyncratic UIs!

And another thing!

So far we have assumed that our approved documents are going to be accessed by consuming viewers, in place. That is to say, approved documents are the same documents accessed by consumers.

However, a better approach, in my view is to completely separate the production space from the consumption space. After all, relatively few users need to be involved in the approval process, but the consumers of a document might be everyone in the entire organisation (say an HR Policy document for example).

To give us an easier system to manage we might consider splitting the process over 2 separate sites, which I call:

• Below the line: The site where the source-of-truth versions of the documents reside and where the approval cycles are managed.
• Above the line: The site where a managed copy of the document is published and made accessible to the wider consumer audience.

The below-the-line site might be a Team site (or an MS Teams Site) whilst the above-the-line space might be the corporate Intranet.

Now this idea might stick in the craw of some information managers as violates the #1 mantra of good information management – have a single source of truth! I side step this dilemma by not thinking of the above-the-line documents as copies but rather think of them as renditions of single source of truth.

This approach will allow us to do something that we cannot do when the document is accessed in place, and that is it allows us to change the format of the document. Typically, the above-the-line renditions are not exact copies of a source document but rather they are presented to users in a format that is aimed primarily at consumers rather than editors – in other words a PDF.

This is also something we might do with the workflow but that would add even more complexity because the workflow now needs to:

• Detect when a new major version of a document has been approved.
• Create a PDF rendition of the document.
• Push the PDF to the above-the-line site and replace any previous version which might reside there.
• Map metadata from the source document to the PDF rendition.

And just to make things more complicated, there might be certain documents that we don’t want converted to PDF (form templates, or PowerPoint presentations for example).

In Summary

In this post I have explained that the standard features that SharePoint provides for version control and content approval, as good as they are, don’t fully address what most organisations need to build a tightly governed approval process such as might be required for the approval, publication and dissemination of Controlled Documents.

SharePoint gives us a one or 2-step approval process, but most organisations will want a 3-step or 4-step process. Plus we have no built-in way to assign tasks to roles or users to roles and so no way to track and monitor the process.

We also have no way of easily separating the system into production and consumer spaces or of making approved documents accessible to users as a PDF

The usual tactic is to use Power Automate to build a workflow which manages the process and deals with the complexity of all that needs to be done in such a system, but I hope I have managed to convince you that the construction and maintenance of such a workflow is not a trivial undertaking and most certainly beyond the skill set we might expect from citizen developers. Such a workflow would likely need to be built by a professional that most organisations wouldn’t have in their team and so the task would need to be outsourced, adding to the cost.

And this complexity would be compounded if there were a need to build workflows for multiple libraries and multiple sites.

So this is why we, at Kaboodle Software decided to build a solution that removes this burden. It provides a role-base approval system that:

• Can be configured for 2, 3 or 4-step approvals.
• Can auto-publish documents to above-the-line locations and optionally convert them to PDF.
• Provide in built in tracking system to monitor when documents are next due for review.
• Send targeted notification emails to the next-in-line stakeholders.
• Is built as a state-machine rather than a sequential workflow
• Does not involve Power Automate, and so there are no additional costs or maintenance overheads incurred by that platform.
• Allows administrators to quick-publish a document when there is a need to side-step the full approval process.
• Can be set up by power users – there is no need for an expensive external developer.
• Looks and feels as though it is a native part of the SharePoint platform and not a separate app.

We call this product K-Docs Approve and in my next post I will go into some detail on how set it up.

And guess what, this is a Freemium product, meaning that you can use the product without a license. Although the Freemium release has certain limitations and restrictions in functionality, it provides a fully functioning solution that addresses the shortfalls of the standard SharePoint product as described in this post. Ty it out, what have you go to lose?