Sharepoint Workflows and why Nintex?

I was asked a lot in the past, since in Sharepoint by default supports creation of workflows to support business process automation, why is there a need to consider Nintex Workflow? In this write up, I am trying to revisit the approaches and steps involved in Sharepoint workflows. With the summary on that, I am hoping to identify key challenges one might face, or benefits one could get if Nintex is in place for the same purpose.

Let's revisit the approaches in implementing workflow in default Sharepoint environment. To simplify, I grouped the approaches into three as summarized in the table below:

Out-of-the-box Workflows

OOB workflows are pre-programmed workflows that are included in Sharepoint, OOB workflows are template driven workflows allowing one to select options with the initiation form when adding the workflow to list or library in a Sharepoint site. Different version of Sharepoint comes with different set of OOB workflows,  Sharepoint 2013 come with - Approval, Collect Feedback, Collect Signatures, Disposition Approval, and Three-State OOB workflows. Here is the link to an Overview of workflows included with Sharepoint provided by Microsoft.

Adding a OOB workflow to a list or library can be achieved by just select the "Add a Workflow" from the list or library's "Workflow Settings" menu in the Ribbon menu. The "Add a workflow" configuration page will be presented allowing one to select a OOB workflow and other configuration values. This is illustrated in the diagram below,

The steps usually involved with an initiation form allow additional assignment of required parameters such as Approvers to be used for the workflow to send or assign a task to. This is illustrated in the diagram below.

OOB Workflows - Key Challenges

OOB Workflows provide a great way to business users for automating business tasks that are seen commonly across different organizations, these are processes such as getting an approval, sharing and collecting feedback on documents. Unfortunately, when it comes to actual implementation, the majority of the time we will need to do more than just getting an approval or changing the status of the document from "Under review" to "Approved".  Most of the time we would need additional tasks to be accomplished such as:

• Sending a notification to the initiator when the item is being assigned to someone for approval
• Copying the document to a destination repository when it was approved or final
• Etc.

You will realize too, you will need to hard code the "Reviewers" in the above "Approval" workflow sample by selecting a person whom you want the document to be assigned to. This could cause a huge maintenance issue or effort if the approver left the organization or switches roles, which happens very often in today's business environment.

Due to this, I find a lot of time we would need to use a Custom Workflow instead of the OOB Workflow that comes with Sharepoint, as it allows us to add own workflow action(s) or steps according to the need for a business process.

Custom Workflow

The second approach for workflow implementation in Sharepoint is the Custom Workflow, which gives us the flexibility to define the steps needed for a business process automation. Sharepoint comes with a set of out-of-the-box Workflow Actions to support the common business process automation. The following is a grouped list of Actions available in the default Sharepoint 2013 installation.

The process involved in implementing a Custom Workflow in Sharepoint can be summarized in the below sequence:

1. Authoring and Deploying a workflow

Defining the process by adding Stages/Steps, Workflow actions, activities, and conditions. Once a Workflow is defined, it will be deployed to Sharepoint as a workflow template available for associating to the list or libraries.

2. Associating a Workflow

A Workflow Template is to be attached/associated to Sharepoint list or content type before in instance can be created or executed.

3. Instantiating a Workflow

Workflow is being executed or instantiated either by manual triggered or when an item is being created or changed.

The designing or authoring of a Custom Workflow has to be done using the Sharepoint Designer IF and ONLY IF encapsulation or coding new Actions is not required to fulfill the business process automation. In the event of new actions being created for the workflow authoring purpose, the programmer will need to create the custom action(s) using Visual Studio for the purpose.

Creating a workflow by using Sharepoint Designer 2013 can be found in the Microsoft MSDN site, details how to install, open, and create a workflow by using SharePoint Designer 2013 and the SharePoint 2013 Workflow platform. In summary it involves steps to

1. Install Sharepoint Designer (i.e. if it has not been installed in your Sharepoint environment)
2. Open or connect to a Sharepoint site in the Sharepoint Designer
3. Creating workflow in the Sharepoint Designer for a Sharepoint environment

The key activities involve in creating a workflow using Sharepoint Designer covers add Actions, Conditions, Stages, Steps, and Loops to build your workflow. These workflow components are available in the ribbon of SharePoint Designer 2013, as shown in the following figure

Custom Workflow - Key Challenges

The Sharepoint Designer extends the capability not just to create Custom Workflow in supporting business process automation, it also provides other functionalities to support Sharepoint site customization such as Page Layout or Page authoring, etc. Unfortunately, when looking at just creating Custom Workflow, the following drawbacks are the key challenges most users find:

• Sharepoint Designer is seen as a designer tool in general Sharepoint site customization instead of just focusing for Workflow development or designing purpose.
• The business process owner or designer will need to install Sharepoint Designer to design Custom Workflow
• By default the Sharepoint Designer supports only the authoring of workflow in a declarative rules-based and text definition/statements, which is not "flowchart" graphical design experience. "Flowchart" style is only available since Sharepoint Designer 2013 but being supported by additional Visio application that will need to be installed separately.
• The need to install additional software(s) to support the Custom Workflow is one key challenges. But the actual issue with workflow implementations is the lack of Workflow Actions supporting the business process automation. Majority of time, when you are creating a Custom Workflow, the default out-of-the-box Workflow Actions (i.e. less than 40 as listed in the previous paragraph) are not sufficient to fulfill the requirement of business process automation, and then IT programmers are loaded with the efforts to program custom actions using Visual Studio.

Nintex Workflow advantages

Just to highlight a few, here is how Nintex Workflow for Sharepoint helps in supporting the workflow design process:

1. Business Process owner or developer can now accomplish the Custom Workflow design process without leaving the Sharepoint environment (i.e. within the browser environment).
2. Nintex Workflow designer supports the workflow design process in a quick and easy manner.
3. Nintex Workflow designer is embedded into a Sharepoint site, without the need for workflow developer or process owner to install additional software to design workflow.
4. Nintex Workflow comes with over 160 default workflow actions to support business process automation, and additional actions can be downloaded from the online "Catalog" (i.e. Nintex store).
5. Nintex Workflow encourages no custom coding of custom actions required, this is achieved with the rich set of Workflow Actions that come with Nintex Workflow installation. In the event that a custom action coding is needed, the SDK provided allows programmers to develop custom actions.
6. The workflow design in a "flowchart" graphical format provides self-explanatory to business users, and reduces tremendous maintenance efforts when it come to changes to the business processes.