Tuesday, December 8, 2009

Starting SharePoint 2010 Site Workflows from code


One of the cool new features of  SharePoint 2010 is Site Workflows. As you probably know, in SharePoint 2007 a workflow can only be associated with a list or a document library. While this functionality is useful, sometimes a “site wide” workflow is called for. This leads to us developers getting creative and producing  approaches such as creating a list called “Site Workflows” and creating items in it that have “start on create” workflows attached to them. In SharePoint 2010 Site Workflows provide an elegant solution for this common scenario.

The Code

 using (SPSite site = new SPSite("http://moss2010beta")) //get the site

           using (SPWeb web = site.OpenWeb()) // get the web
                        //find workflow to start
                        var assoc = web.WorkflowAssociations.GetAssociationByName("Demo Site Workflow", CultureInfo.InvariantCulture);

                        //this is the call to start the workflow
                        var result = site.WorkflowManager.StartWorkflow(null, assoc, string.Empty, SPWorkflowRunOptions.Synchronous);


As you probably have noticed, the API call to start a site workflow is not much different form the call to start a list workflow. A new overload was added to SPWorkflowManager.StartWorkflow() method. This is the method we call to programmatically start our site workflow. One new parameter of this overloaded method which deserves a mention is the runOptions parameter, which expects a SPWorkflowRunOptions enumerator. See MSDN page for details.

Possible uses of the code

I believe that Site Workflows in SharePoint 2010 bring even more flexibility to an already powerful workflow infrastructure that the platform currently offers. There are many examples I can think of where one would use site workflows, but one specific one is on the top of my list. Say you have an application built on top of SharePoint 2010, which, when installed, adds whole bunch of custom lists, event handlers and workflows to the site. Now imagine if some of the major “events” or “states” of that application are implemented as site workflows created in SharePoint Designer 2010, which at any given point are started from event handlers or other custom code. Say that one such site workflow is run by the application when a document of a specific content type is checked in to the system by a user in a specific SharePoint group. The default site workflow is set to notify the content steward by email. If one of the SharePoint Designer 2010 savvy users wants to change that to create a whole review process or create a task or a list item in another list, they can. The point is,  Site Workflows can be used to add extensibility points to an application build on top of SharePoint, which require only SharePoint Designer power user to take advantage of.  In conclusion, I hope that this article will help someone out there build smarter solutions to common business problems on top of the upcoming  SharePoint release.

Sample Code Download: SiteWorkflowStarter.zip