Sometimes technology makes some scenarios worse.

At our last Nintex User Group in Detroit, I presented an approach for solving small scale static approval processes (it was met with raving reviews – and lots of questions).

The issue:

The use of Nintex Flexi-tasks and Approval tasks are the standard tools to notify and gather approval feedback. They are feature-rich, scalable, and easy to use. However, they present a few barriers:

• Reporting: The SharePoint list item and process data are not in the same data-set. Since approval tasks are stored in a separate list, and their comments, in order to get a consolidated view of both the SharePoint list item and process approval history, you have to combine the one to many data sets either on the SharePoint list form or through some tricks with excel.
• User Experience: Users have two locations they will need to access the SharePoint list item or document that is being reviewed and the task approval form. This means the user has to open the item or document they want to review and then go back to the email notification to open the form in order to indicate their decision and comments. That is a lot of screens and based on C/D/H now Red Level’s UX experience, less is more!

The Approach:

Denormalize the SharePoint Item or document data and process data. Translation: create fields in the SharePoint list for your business process and also fields to store the process information. For example, if I had an expense report list, I would include Employee, Submission Date, Date Range, Total, but also would include fields like Approver 1 Name, Approver 1 Date, Approver 1 Comment, Approver 2 name, Approver 2 Date, Approver 2 comment.  This way I will have one data set will all the information for the expense report and the approvals.

Benefits:

• User Interface – Creates a single form for easy access for submitter, and approver. The form will have a section for the expense report and another section for the approvers.
• Reporting – Business fields and process fields are consolidated in one list for easy reference in SharePoint views, and in Excel for downloading.
• Process simplification – Since all the process data is stored with the business lists data, it can be referenced through Nintex Workflows “Item Properties” That means your workflow will not have to grab the comment from a second list, and concatenated them into a large comments field within the business list. They are just there.

Technology Barriers:

With this approach, there are a few technological challenges that don’t exist if you use an approval task.

• Problem – Stopping the workflow to wait for Approvals. A workflow is paused while it waits for the outcome of an assigned task. With no tasks how do you now pause the workflow until approval content is gathered?Solution – This is best done with the Nintex workflow action Wait for Value change. That is configured to wait until the Process Step field is changed to the next step in the process. Note: the process step field would be a choice field with the list of steps the process goes through.

• Problem – User interface to move to the next step. Without approval tasks, we need to have a way for the users to indicate they are done with their review.Solution – Add buttons to the form that save and close the form but are also connected to the Process Step field to move it to the next set. The workflow is paused waiting for the process step to change. The button pitches the value and the workflow catches and moves on.

• Problem – Permissions of approvals: in order for this approach to work permissions are open on the list for edits. Solution – Use Nintex forms rules to lock down sections based on the process step. For example, I would lock the expense report area when then

The traditional model of using approval task and flexi-task are feature rich with reminders, escalation, delegation, and scalability. However, for smaller more static processes try consolidating the process data on a single form and using a new approach.