Now available, SharePoint 2010 Development with SharePoint, a comprehensive and fun guide to developing rich, interactive SharePoint solutions with Silverlight.
Last week a customer asked me a question that many others have asked before: “When should I create my workflow in Visual Studio vs. SharePoint Designer?” This question has puzzled so many of my clients that I decided it was time to write a blog posting on the subject.
To review, there are actually four options for workflow in SharePoint technologies:
1. SharePoint Designer can be used to create workflows through a wizard user interface that resembles the rules editor in Microsoft Outlook. Workflows can be created and edited by an analyst or savvy user. The list of conditions and actions in the wizard can be extended by a developer using Visual Studio. (for more details please see the previous posting).
2. Visual Studio can be used to create workflows. It’s easy to add .NET code, so developers have a lot of flexibility in what they can do, but it’s definitely a developer activity. Creating these workflows is much easier with Forms Services (available in MOSS Enterprise Edition and SharePoint Forms Server) than if each form must be developed as a discrete .aspx web form.
3. MOSS 2007 includes several built-in workflows: Approval, Collect Feedback, Collect Signatures, Disposition Approval , Three-State and Translation Management. These allow extensive configuration by site administrators. Ed Hild has pointed out that the built-in “approval” workflow can be extended by adding an event handler to the “approved” event on a forms library (http://blogs.msdn.com/edhild/pages/using-oob-workflows-to-provision-sites.aspx) … the form holds a request, the built-in workflow mediates the approval of the request, and if the form is approved, the request is carried out by the event handler. Very clever!
4. A number of 3rd party workflow products are available such as K2.Net, Skelta, Captaris, Ultimus and I’m sure many others. Many of these products are more mature than the workflow offerings provided by SharePoint technologies, and have built-in provisions for escalating work in an organization, advanced tracking and reporting, etc.
Everybody likes to have choices, but sometimes having so many options can be confusing, and this post will try to help.
First stop is the “out of the box” workflows. They’re really quite powerful and configurable. Why build a custom workflow at all if you don’t have to?
A commonly overlooked “out of the box” workflow is the Three-State Workflow. No, this is not a workflow for use when you’re in a place like Port Jervis (which straddles New Jersey, New York and Pennsylvania)! It’s really a two-stage approval workflow, and thus it can be in any of three states, such as waiting for first approval, waiting for second approval or completed. It requires a “choice” field in the content with at least three choice values to correspond to the three states. The three-state workflow is often overlooked because its feature is not enabled by default … to use it, go to Site Collection Features and enable the “Three-State Workflow” feature. It’s worth a try, as it’s pretty flexible!
If the “out of the box” workflows don’t have what you need, then by definition we’re looking at a custom workflow. Personally I like SharePoint Designer workflows because they are the easiest to set up and modify, however there are some limitations you need to be aware of. First of all, they are edited live on a SharePoint site; there is no easy way to have a software lifecycle with controlled releases going through a build and test environment. Second, they are set up on a library by library basis, so there’s no easy way to distribute and manage the workflow across many document or forms libraries, or to connect them to content types. Finally, they are always sequential workflows, meaning they run from start to completion (as compared with state machine workflows which are best for modeling ongoing processes where work moves among a known set of states). In practice, most workflows are sequential, so that’s not a big deal. The net of it is if a workflow is a “one-off” and business users own the process, let them manage it themselves with SharePoint Designer workflows. Empowerment is good. This provides the business with more flexibility and agility.
If the workflow needs to be associated with many libraries or a content type, then it will need to be created by a developer. In addition, many organizations will prefer a formal development process, especially for business processes that have financial or regulatory impact.
If the desired workflow resembles one of the built-in workflows followed by some additional actions, consider Ed’s event handler idea.
Otherwise, it’s time to go into Visual Studio and create a workflow using the workflow templates in the SharePoint SDK. This allows developers to take advantage of the full power of .NET in a full software lifecycle; it also allows state machine workflows. There are a number of resources including videos and webcasts in the Workflow Resource Center on MSDN.
Finally, if the solution needs to have additional workflow features that would be expensive to develop, such as escalations, vacation schedules and advanced reporting, then consider a 3rd party workflow. A marketplace of options evolved during the 2003 versions of SharePoint, which lacked its own workflow, thus encouraging our partners to invest in this area; now these 3rd party products can offer higher-end workflow for customers who need it.
I hope this has been helpful in selecting a workflow option for your MOSS 2007 solution!
This posting is provided "AS IS" with no warranties, and confers no rights. Thank you for reading it!