Approval Workflows in SharePoint

A SharePoint approval workflow supports the business processes in companies, because it manages all tasks related to approval and forwards them to the appropriate people, for example sending a document for approval to colleagues or superiors. What exactly is the concept behind it? And what questions should you ask yourself before starting an approval workflow?

The Starting Point

Let us imagine a typical starting situation that is always asked for in this or a similar form: Documents are processed in a SharePoint document library, regardless of whether with or without a folder structure. The documents are subject to versioning and must be approved before publication.

A fixed group of employees has approval rights. But not every authorized employee is actually responsible for every document. They are often only responsible for part of the documents and should only be allowed to approve them. They may also need the option of having multiple instances of approving your document, or they may have documents that do not need to be approved.

In addition, employees have reported that the standard approval process for SharePoint workflow, which they can use ‘out of the box’, does not exactly represent an intuitive operation in the interests of the users.

A Typical Catalog of Requirements for Approval Workflows

Before you begin, get an overview of your approval process requirements. They can be derived as follows:

• A version history with major and minor versions is required for all documents
• All documents are to be integrated based on metadata (department, document type such as contract, offer, work instructions; presentation, etc.)
• The selection values ​​for the metadata should be managed separately
• Depending on the document grouping (inclusion in the metadata)

• No approval take place (immediate publication).
• An approval process is started that authorizes an employee to release this document group, whereby the various approval groups must be administered administratively and can change daily.

• Depending on the role of an employee in the approval process, various emails must be sent to him. On the one hand to inform about the responsibility of an approval task and on the other hand to inform about the progress of the approval process by email.

Of course, such a catalog can be filled much more precisely and with additional requirements. The following requirements are just an example:

• Representative regulations (replacement permits).
• Escalation processes.
• Automatic request for read confirmations after approved publication.
• Change request management.
• Process and archiving.
• Parallel and / or serial processing of approval tasks.

The Choice of Technical Means: Approval Workflows ONLY with SharePoint

Regardless of your catalog of requirements, the solution should:

• Implemented with on-board resources from SharePoint.
• Can be implemented without the use of third-party tools.
• Can be used for all SharePoint versions (Foundation, Standard, Enterprise).
• Be possible without using InfoPath forms.
• Can be realized using SharePoint Designer workflows.

The choice of funds is technically limited and therefore includes the following components:

• SharePoint infrastructure with e-mail outbox (fully configured).
• SharePoint website with SharePoint document library, in addition to process-supporting SharePoint lists (more on this in a moment).
• SharePoint designer workflows (without ‘out of the box’ workflows).

Process Modeling

Based on the requirements, it is advisable to create a detailed flow diagram of the process, which is the starting point for planning and the conception of the technical implementation. An exact flowchart is not shown here because the focus of the article is on the technical implementation, which can be used universally.

Technical Conception

At the beginning of the technical conception phase, the information in the catalog of requirements and that of the planned flow diagram flow and result in a very simplified way, the following schematic process flow:

Taking into account the selected platform SharePoint, including all specific characteristics & requirements, first derivations can now be made:

• A workflow starts at the point in time when a document is uploaded for the first time (trigger: new element) is obsolete, since a document remains after the first upload in the approval status ‘draft’ (minor version), which is not started due to the system (property of major and minor version)
• A workflow is only started when the approval status ‘Pending’ is reached and the user has selected the ‘Publish major version’ option (property of major and minor version)
• All data fields involved in the approval process exceed the limit of libraries in the proposed project and would not allow intuitive operation (SharePoint limits). It is therefore necessary to distribute the proposed process over several lists in addition to the document library.

Regardless of other possible derivations, which are not considered here, the approval process can be transferred to SharePoint as follows:

In order to be able to control documents based on their properties (metadata) with different approvers, a list of these people is required in order to be able to reflect the relationships. Both the ‘Documents’ library and the ‘Approvers’ list use a special mix of metadata. The so-called metadata source can also simply consist of columns with dropdown values, which are available in the document library and the approver list in the same form. The aim is, for example, to have the documents of branch X Type Y approved by persons A, B and C. Documents of branch Z of type Y, however, by persons M, N and H. In the ‘Approver’ list, a list element specifies for which compilation of branch and type, a person the documents of a special integration of the document in metadata, then approve such a document. The workflow ‘Process’ then knows the metadata of the document and uses it to find the required people in the ‘Approvers’ list.

Start & Initiate The Approval Process

If a document is published by the user, it is in the approval status ‘Pending’. Due to the change (due to publication) in the document, the ‘Approval’ workflow starts in the ‘Documents’ library and creates an element in the ‘Approval processes’ list. Afterwards, the ‘Approval’ workflow remains in the waiting position until the process ends. There is a field for this on the document, which is waiting to be changed. The field must be filled initially when an approval process starts, so that a change can also be intercepted at the end of the approval process.

Creation & Initiation of Approval Tasks

By creating the element in the ‘Approval processes’ list, the ‘Process’ workflow starts and looks up the required metadata of the document in the ‘Documents’ library. With this metadata, the workflow looks up the required people in the Approvers list. An element is then created for each approver in the ‘Approval tasks’ list that represents the respective task for the relevant person. The name, the approval decision and the assignment (binding) to the element are stored in this element. Furthermore, a field for the entire approval status is kept in this element and initiated with the content ‘Pending’. At least the name, the approval decision (initially ‘pending’), the assignment to the document and the assignment to the approval process are saved in the newly created element of the ‘Approval tasks’ list for each approver. The workflow ‘Process’ ends afterwards.

Assignment of The Approval Task(s)

By creating the new element created in the ‘Approval Tasks’ list, the ‘Task’ workflow starts there. He sends the authorized person an email with his approval task. Then the workflow ‘Task’ ends.

The email should include brief instructions that briefly explain to the approver what to do, a link to the document to approve, and a link to the approval task. The approval task should be restricted to the fields ‘Approval Decision’ (pending, approved, rejected) and ‘Approval Comment’ in the edit view via the content type management.

Approval Decision by The Authorized Person

An approver receives an email and uses the links included to make his decision. Usually this happens for several people at different times.

Processing of The Approval Decision(s)

Once an approver has given his decision, the ‘Task’ workflow starts again and updates the element in the ‘Approval Processes’ list to which it is subordinate. Then the workflow ‘Task’ ends again. The red arrow drawn in the illustration, which points back from the workflow ‘Task’ to the element ‘Approval task’, is optional and indicates that you have the option to save further information when the approval has been received (e.g. date of rejection).

Processing of The Overall Approval Decision

Due to the change that is triggered in the element of the ‘Approval Processes’ list, the ‘Process’ workflow starts again and checks all decisions of all approvers of its process for pending approvals. If there are still any, the ‘Process’ workflow ends and waits for the next trigger from the ‘Approval Tasks’ list. If, on the other hand, all decisions have been received, an overall approval status has resulted, which results in either ‘Approved’ or ‘Rejected’. This status is then entered on the document (the ‘Approval’ workflow is waiting in the field for its field change). Then the workflow ‘Process’ ends.

Approval/Rejection of The Document

By changing the field on the document, which now has the overall approval status, the workflow ‘Approval’ continues and changes the status for content approval for the document to ‘Approved’ or ‘Rejected’. Then the approval workflow ends.

Conclusion

This article is intended to put you in a position to implement the basic scheme shown in practice and to expand it further according to your requirements. Depending on your very special requirements, you can adapt and expand the modeling to your needs. Afterwards it is recommended to carry out further steps:

• Creation of a data model that reflects the details of each library and list at field level as well as the metadata used (if necessary in a separate metadata concept) and views of the data in SharePoint. Please also note that there are hidden fields that are required for the functionality, but are / must not be visible to the user.
• Creation of an authorization concept that shows who can view which documents, approval processes, approval tasks, approvers, or who can create and / or change them. Note that views of data in Web Part Views can also require permissions. This technical means can also be used profitably.
• Implementation, documentation, testing and activation for use.