This might include scenarios like:
- Vacation and leave requests and approvals
- New employee account and hardware/software approvals and provisioning
- Project and budget tracking and approvals
- New site provisioning
- Customer self service
Available Toolsets
In order to meet business needs for workflow within SharePoint, we have traditionally had three options available to us:
- Configure out-of-the-box SharePoint workflow
- Implement workflow using SharePoint Designer
- Implement workflow with custom code using Visual Studio
Since the early days of SharePoint 2007, we've implemented workflows for clients using all three of these methods and gained considerable experience writing custom workflows to support unique business needs. Each of these three approaches has pros and cons.
Is it better in SharePoint 2010?
Although the introduction of SharePoint 2010 brought some notable improvements to out-of-the-box and SharePoint Designer workflows, the challenges are more-or-less the same as described above. This article on SharePointProMag.com provides a useful summary of the improvements to Workflow in SharePoint 2010.
The 60 day surprise
A common issue that affects all of the above three implementation scenarios is the automatic clean up of workflow history after 60 days. Most business users make the assumption that the workflow history on an item will always be available (e.g., they can always go back and see who approved a request, when they approved it, and their comments.) They start using a workflow and it works just fine for them initially and they perhaps give up their paper based process for tracking these approvals. Then after a couple of months of using SharePoint workflow, they get the nasty surprise that the workflow history information is no longer available!
There is a lot of misinformation out there about what actually happens after 60 days. The workflow history items are not actually deleted; however, the association to them (and the ability to view them through the status page of a particular workflow instance) are no longer available. See this short article on Technet for a good description of this "Disable automatic cleanup of workflow history" (although it refers to SharePoint 2007 it is also applicable to 2010). The article actually describes a workaround of disabling the timer job that performs the workflow cleanup; however, this is not really recommended due to the potential impact to performance of allowing these lists to grow indefinitely.
The cost of custom workflows
With the limitations that come along with OOTB workflows and even SharePoint Designer workflows, it's very tempting to build custom workflows in code using Visual Studio. Custom code workflows are certainly very powerful and you can implement functionality with very few limitations; however, we have found them to be very expensive — not only the initial implementation, but the maintenance of them. Plus, they're just not much fun to work with! There is a steep learning curve, even for a very experienced SharePoint developer, and the challenges of troubleshooting and debugging them can make them quite frustrating.
There have been many instances where a business user would like to make a change (e.g., adding an approval step in the workflow) that one would expect to be easy enough, yet the effort/cost of making the change, deploying, testing, and handling versioning of the workflow (so as not to impact running workflows) make it prohibitive. One often needs to wait until there are several changes required and bundle those up together and sometimes create a mini-business case to justify and validate the cost vs. value. This is rather frustrating for our clients and for us. One of the objectives of the sustainment work we do is to enable our clients to "adapt quickly to changing business needs". Workflow has been one area where this has been very challenging to achieve with the tools available to us with SharePoint.
There must be a better way!
It became pretty clear that we needed a better way of addressing our clients' needs for implementing workflows in SharePoint to support their business processes. While with custom workflows we can meet almost any functional requirement, the cost of implementation is not very well aligned with the value the client receives from a particular workflow. We needed a solution that:
- required much less effort to implement
- was maintainable (e.g., adding a field to a form or adding an additional workflow step is a low effort and low risk process)
- allowed for publishing new versions of a workflow (while in-progress workflows continue to run) in a stable and predictable manner
- handled the 60 day workflow history challenge in a consistent way (without having to put in a workaround or some customization in each instance)
- was easier to troubleshoot and diagnose issues with a workflow
- had a reasonable learning curve (i.e., not the steep learning curve and specialization required for developing custom workflows with Visual Studio)
As the SharePoint platform has matured over the last several years, there has been an explosion in the number of ISVs building third party products for SharePoint. We investigated several that have workflow related products and settled on Nintex as the most promising to meet our clients' needs.
