The complete workflow story was significantly improved in SharePoint 2010 over the previous version’s story as Microsoft invested in SharePoint Designer 2010 (SPD2010) capabilities in creating custom workflows with the SharePoint 2010 release. SPD2010 is a tool that can create powerful declarative workflows, but previous versions were dismissed by many because its workflows were tied to a specific list at design time. That meant there was not a good option for creating and deploying workflows with a simple copy-paste deployment between a development and production environment.
SPD2010 changed this with the ability to support reusable (aka content type) workflows that could be created in one environment, saved as a sandbox solution package, and easily saved and deployed to another environment. It also received other very important improvements such as impersonation steps, a better workflow designer, the ability to import Visio 2010 authored workflows, and a significantly improved task approval process designer.
Challenges with SharePoint Designer 2010 based Workflows
However with all these improvements, a few things still lead people to dismiss SPD2010 as their workflow tool. For instance SPD2010 can’t support loops or state machine workflows. SPD2010’s declarative workflows are limited to sequential workflows that can have decision points (“IF” statements), but there is no looping process.
In addition, SPD2010 doesn’t provide low level debugging or elevation of privileges when you have a need to do so in the business process. Debugging is limited to monitoring what inputs are provided to the workflow and how it reacts. Another big limitation of SPD2010 authored workflows is that they can only access content within the same site where they’re running; they can’t access content from other sites, site collections or external feeds, and Web services.
Challenges with Visual Studio 2010-Based Workflows
Many customers concluded their only option was to move to Visual Studio 2010 (VS2010) for creating their workflow solutions. This presented other challenges, though. For instance, all VS2010 workflows are code based and must be deployed as fully trusted farm solutions; it’s not possible to deploy a workflow built in VS2010 to the sandbox. VS2010 workflows are usually built only by developers, not by power users or the business analysts who best understand the business process being automated by the workflow.
Addressing SharePoint Designer 2010 Limitations
What I saw in the first few months after SharePoint 2010 was released was that many people were still in what I considered the SharePoint 2007 mode of thinking with respect to workflow. This thought process usually involved ditching SPD2010 as the workflow tool and moving over to building the workflow with VS2010 when one of the aforementioned limitations was encountered. I find this to be quite disappointing because building workflows with VS2010 leaves a lot on the table. You lose the ability to have declarative-only workflows that can be deployed to the sandbox, your developers aren’t in charge of building a business process, and worst of all, there’s more custom code that needs to be maintained.
The reason this is so disappointing is because what I typically see is that the majority of the workflow process can be expressed using SPD2010, with only one or two small pieces that SP2010 can’t handle. These few pieces push people to VS2010. The analogy “throwing out the baby with the bathwater” comes to mind. Instead of throwing the whole workflow out, why not address the problem?
One option available to customers is to have a developer empower those building workflows with SPD2010 by using VS2010. This is facilitated by creating a custom action (otherwise known as an activity) with VS2010 and deploying it to SharePoint 2010. The next time someone opens the site in SPD2010, the custom action will be available in the last of actions that can be used in the declarative workflow. These custom actions can be deployed either to the sandbox or as a fully trusted farm solution and are scoped to a particular site collection.