CHALLENGE #7 IN IMPLEMENTING SHAREPOINT: Running workflows after the error
SharePoint Feature Description
SharePoint 2013 workflow engine is the main focus of implementing business processes in Microsoft SharePoint. There are three options when you want to design and implement business processes inside Microsoft SharePoint technologies.
- To use the out-of-the-box SharePoint Workflows (Approval, feedback,…)
- Create a custom workflow with SharePoint Workflow Designer
- Create a custom workflow in Microsoft Visual Studio.
If you want to create advanced business processes with custom complex rules, the only available option is to use the Visual Studio and program the workflow using the Microsoft Workflow Engine.
In our test implementation of Microsoft SharePoint, there are a couple of workflows for proposal creation and other major business activities. These workflows are created in Visual Studio to address the business requirements.
SharePoint Challenge Description
It is possible for custom workflows which is developed in Visual Studio on a heavy loaded sites and different users to end up with an error. The root cause of the error may be a variety of reasons. But when a running workflow encounter an error, the entire workflow is shut down and there is no way to restore the workflow to the before-the-error-state and continue the remaining steps of the workflow. You have to terminate it and run it again from the beginning.
Consider an approval workflow which goes to 10 different people serially in the organization to get the approval on a document. If we are in the step number 9 and we face an error, there is not possible to fix the error and continue the process. The entire workflow should be terminated and you have to begin from step number one which is very annoying for users. This will introduce lots of rework and the user experience damages badly.
There is not any solution for this challenge available at the current revision of SharePoint. It is a very good idea to be able to restore a single workflow to a previous state in the SharePoint. Currently we just program our solution to show the stack trace of the error in the workflow history, so we can narrow down the possible root cause of the workflow failure.