Sometimes, configuring workflows can be a real struggle. Especially when you want to have as few (performance) issues as possible.

I got into a challenge where I needed to create a workflow solution for a process driven Document Management System and prevent performance issues and error occurrences but still keep the solution easy to use and easy to manage.

The case

For a process driven Document Management System, I had to create a workflow solution within SharePoint 2013 in which the user could perform a series of dossier/document related tasks inside a document set:

Dossier related tasks

• Create a new mandatory document
• Create a new optional document

In both cases, when the user completed the task with an outcome where the document is uploaded, there had to be a check if the document was actually added to the dossier. In case of an optional document, the user was provided with the option ‘Not necessary’. When this option is chosen, no check will be performed.

• Perform a common task on the dossier

Document related tasks

• Review a document
• Approve a document
• Digitally sign a document (internal and external)
• Perform a common task on the document

Also, an option must be available for a power user to change the process step without crashing the workflow and all closed non-process driven dossiers must been archived every first of the month.

The challenge

Of course, there is a possibility to create a single looping/state machined workflow on the dossier that starts on the creation of the document set that switches to the entire process defined inside the workflow and end at the end of the process, but that means the workflow will run for a long time with the risk of erroring somewhere during the process. Also, if you use just one workflow, it means that you only have one Workflow History List and one Task List in which you will soon reach the 5,000-item limit.

I also wanted the process definition to be managed easily and not require the process owner to create a change request for a simple process change (e.g. add or edit a process step).

So I had to come up with another solution.

The solution

I created a solution which contained the following:

Document Center Site collection

• Custom List
• Document Library with document sets included (for dossiers)
• Nintex Workflow
• Muhimbi for converting documents to PDF/A
• CoSign for digitally signing documents internally
• DocuSign for digitally signing documents externally
• iWriter for document creation

Record Center Site Collection

For archiving the finished dossiers

Content Type Hub Site Collection

For publishing Dossier en Document content types across both Site Collection

Within this blog, I will focus mainly on the process/workflow solution itself which lies within the Document Center Site Collection.

Process

For the process definition to be manageable, I created a custom list in which each process step needed to be created with the following information:

• Process states the process which the process step relates to. I used a Managed Metadata field.
• Step states the process step title. I used a Lookup field to another list where all process steps were listed.
• Document type states the type of document that is used within this step (eg. Invoice). I used a Managed Metadata field.
• Optional? states whether or not the document is optional within the context of the dossier. I used a Yes/No field.
• Status states the status that the document should have when the process step starts (eg. To be approved). I used a Managed Metadata field.
• Outcome states the status that the document should have when the process step ends (eg. Approved). I used a Managed Metadata field.
• Next step states the next process step that should follow when the current step completed. I used a Lookup field to another list where all process steps were listed.

Table 1. Example Process Steps

The workflow then could address this list to complete each step based on the outcome of a step.

This way, the amount of actions in the workflow will be reduced which would lead to better performance. Also, a (power) user could manage the process definition without any knowledge of Nintex.

To prevent the task list from quickly reaching the 5,000-item limit, I wanted to have a single Task List for each specific type of task (eg. Approval task list). As you can read above, that meant I needed a minimum of 7 Task Lists and therefore a minimum of 7 workflows to conform to this. This also meant I needed a minimum of 7 Workflow History Lists.

Change the process step

The ability for a power user to change a process step can’t be done by simply changing the ‘Step’ metadata field on the dossier, because the workflow will lose its current process step and eventually crash.

Therefore, a new workflow was introduced which can only be started by a user with Manage Lists permissions (which in this case is the power user). This workflow has a Variable ‘Step’ which is a Required Start Variable (and is shown on the workflow start form). When the workflow is started, the user has to fill in the name of the process step of which the dossier should be changed to. After that, the workflow will terminate all running workflow instances, change the process step of the dossier and will start the main workflow again.

Archive non-process driven dossiers

In some cases, dossiers were (automatically) created but didn’t require a process to follow. This meant that a process driven workflow as described above couldn’t be used. These dossiers however do need to be archived at some point. Because there was no process workflow, the process step of archiving the dossier can never be reached automatically. The user has to manually specify that a dossier should be archived by using a checkbox named ‘Archive’.

For archiving the given dossier(s), a scheduled site workflow was used that ran every first of each month. This workflow loops through every non-process driven dossier that has ‘Archive’ checked. When a dossier is found, the Archive workflow will take care of properly sending the dossier to the Records Center Site Collection.

Starting workflows

Another issue that popped up was how to start the next workflow from the current workflow. Of course, you can use the Start Workflow action, but within Nintex this only works if you want to start a new list workflow on the current item. Since the main workflow has been created as a Reusable workflow to run only on start for a specific content type (workflows shouldn’t be started automatically on all documents, only on specific dossiers) the option to Start a List workflow wasn’t available. If the next workflow wasn’t a list workflow or the workflow should be started on a different item, I used the ‘Call web service’ action from Nintex to start the next workflow through a web service.

More information about this action can be found here.

Reusing actions

To keep the workflows easy to manage, I used Nintex User Defined Action (UDA) for (a set of) actions that occur multiple times, such as:

• Start the next workflow
• Get documents inside a dossier
• Convert documents to PDF/A
• Etc.

This way, you only have to define the (set of) actions once. If a change is needed, you only have to execute the change once. After publishing the UDA, all workflows that use this UDA can be provided with the new UDA version with one click.

The final workflow ‘architecture’ looked like this: