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:
Automate common business tasks such as getting approval or collecting feedback on documents
Within Sharepoint environment via browser
Define from scratch with customer business process logic or states. Opportunity to assign own workflow actions that are made available default Sharepoint installation
Custom Workflows with customer actions/activities
In the event if the default workflow actions do not fulfilled the business process steps requirement. Programmers can encapsulate customer code in new actions.
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:
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.
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.
Document Set Actions (not available in SharePoint Foundation)
Relational Actions (not available in SharePoint Foundation)
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
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:
Nintex Workflow advantages
Just to highlight a few, here is how Nintex Workflow for Sharepoint helps in supporting the workflow design process:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.