Choose a workflow authoring tool (SharePoint Foundation 2010)

Applies to: SharePoint Foundation 2010

Developers of workflows can choose Microsoft Visual Studio 2010 or Microsoft SharePoint Designer 2010 as authoring tools.

What is a workflow? Fundamentally, it consists of two things: the forms a workflow uses to interact with its users and the logic that defines the workflow’s behavior. Understanding how workflows are created requires knowing something about both.

Because it communicates with users through a Web browser, a workflow relies on ASP.NET to display its forms. Accordingly, those forms are defined as .aspx pages. A workflow can potentially display its own forms at four points in its lifecycle:

• Association: When an administrator associates a workflow template with a particular document library or list, he might be able to set options that will apply to every workflow instance created from this association. If a workflow author chooses to allow this, she must provide a form that lets the administrator specify this information.

• Initiation: The initiator of a workflow might be allowed to specify options when he starts a running instance. In the approval scenario just described, for instance, the options included specifying the list of workflow participants and defining how long each one had to complete his or her task. If a workflow allows this, its author must provide a form to allow the initiator to set these options.

• Task Completion: The running workflow instance must display a form to the participants in the workflow to let them complete their task. This form is what allowed the approvers in the earlier scenario to make comments on the document and indicate their approval or rejection.

• Modification: The creator of a workflow can allow it to be modified while it’s running. For example, a workflow might allow adding new participants after it has begun executing or extending the due date for completing tasks. If this option is used, the workflow must display a form at this point to let a participant specify what changes should be made.

Workflows built solely on Microsoft SharePoint Foundation 2010 define their forms as .aspx pages. A workflow’s logic is always defined as a group of activities, just as with any workflow based on the Windows Workflow Foundation (WF). To specify the logic and forms for a workflow, Microsoft provides two different tools, each targeting a different audience. Software developers can use the Workflow Designer feature of Windows Workflow Foundation. This tool runs inside Visual Studio 2010 Professional Edition and provides a graphical environment for organizing activities into workflows. Information workers, a less technical group, can use Microsoft SharePoint Designer 2010 to create workflows without writing code. The next two sections examine how workflows can be created by using each of these tools.

Authoring workflows with Visual Studio 2010 and WF Workflow Designer

In many ways, a workflow is like a flowchart. Given this, it makes sense to provide a graphical tool that lets developers specify a workflow’s actions. This tool is SharePoint Workflow tools in Visual Studio 2010 Professional, which is a project type that uses the Windows Workflow Foundation (WF) Designer, and adds deployment and forms support for SharePoint Workflows. Developers can use WF Workflow Designer to define graphically a workflow’s activities and the order in which those activities will be executed. The screen below shows a simple example of how this looks in Microsoft Visual Studio.

Collect Feedback Workflow

The activities available for use appear in the Toolbox on the left side of the screen. A developer can drag these activities onto the design surface to define the steps in a workflow. The properties of each activity can then be set in the Properties window that appears in the lower right corner.

The Base Activity Library Windows Workflow Foundation provides a group of fundamental activities, as described earlier. Microsoft SharePoint Foundation also provides a set of activities designed expressly for creating workflows. Among the most important of these are the following:

• OnWorkflowActivated: provides a standard starting point for a workflow. Among other things, this activity can accept information supplied by a SharePoint administrator by using the Association form when the workflow is associated with a document library, list, content type, or site. It can also accept information supplied by the Initiation form when the workflow is started. Every workflow must begin with this activity.

• CreateTask: creates a task assigned to a particular user in a task list. For example, the approval workflow in the scenario described earlier used this activity to add a task to the task list used by each of the participants. This activity also has a SendEmailNotification property that, when set to true, automatically sends an e-mail message to the person for whom this task was created.

• OnTaskChanged: accepts information from the Task Completion form. The approval workflow in the earlier scenario used this activity to accept the input of each participant when the document was approved.

• CompleteTask: marks a task as completed.

• DeleteTask: removes a task from a task list.

• OnWorkflowModified: accepts information from the Modification form, which can then be used to change how this instance of the workflow behaves. If the workflow’s creator chooses not to include any instances of this activity in the workflow, that workflow cannot be modified while it’s running.

• SendEmail: sends e-mail to a specified person or group of people.

• LogToHistoryList: writes information about the workflow’s execution to a history list. The information in this list is used to let users see where a workflow is in its execution, look at the workflow’s history after it’s completed, and more. To allow this kind of monitoring, the workflow’s author must write information to a History list at appropriate points in the workflow’s execution. Because it provides its own mechanism for tracking workflows, Microsoft SharePoint Foundation doesn’t support WF’s standard tracking service.

A typical pattern for a simple workflow begins with an OnWorkflowActivated activity, and then uses a CreateTask activity to assign a task to a participant in the workflow. The BAL’s standard While activity might then be used to wait until the user completes the task. To learn when this has happened (perhaps the user makes multiple changes to the task, then checks a box on the Task Completion form when she’s done), an OnTaskChanged activity executes within the While, extracting whatever information the user has entered on that form. When the user has completed the task, a CompleteTask activity might execute, followed by a DeleteTask. The workflow can then go on to the next participant, using CreateTask to assign a task to him, and so on. And of course, other things can occur, such as sending e-mail, logging information to the history list, or even including the BAL’s Code activity, which allows running arbitrary code.

All of the activities provided by SharePoint Foundation are concerned with letting workflows operate within the SharePoint environment. The business logic a workflow implements is entirely up to the creator of that workflow. In fact, a developer authoring a workflow is free to create and use her own custom activities—she’s not required to use only those provided by SharePoint Foundation and WF.

As described earlier, Windows Workflow Foundation supports sequential, parallel, and state machine workflows. A workflow created with the WF Workflow Designer can also use any of these options. To allow this, SharePoint Foundation adds project types to Visual Studio, one for each of these workflow styles.

Whatever style is chosen, the developer must define more than just the workflow’s logic; he must also specify the .aspx form it should use. To do this, the developer relies on a file named element.xml. This file provides a template that the developer fills in to specify what form, if any, should be displayed at each of the four points at which a workflow is allowed to do this.

A developer must do some work to pass information between a workflow and the .aspx forms it uses. The Microsoft.Windows.SharePoint.Workflow namespace exposes an object model for developers. Using the types in this namespace, the creator of a workflow can pass information from an .aspx form to the workflow and vice-versa.

Once a workflow and its forms have been created, the developer must package them into what is referred to as a Feature. A SharePoint administrator must then install this Feature, which includes installing the workflow’s assemblies to the target system’s global assembly cache. The new workflow will now be visible to the administrator as a workflow template that can be associated with a document library, list, content type, or site.

For a software developer, creating a workflow by using Visual Studio and the WF Workflow Designer isn’t especially hard. The developer needs to understand the specifics of working in this environment, but much of what he’s doing will be familiar. Yet software developers aren’t the only people who’d like to author workflows. As described next, people who aren’t professional developers can also create workflows by using Microsoft SharePoint Designer 2010.

Authoring workflows with Microsoft SharePoint Designer 2010

Microsoft SharePoint Designer 2010 is a separate application that is available as a free download. Microsoft SharePoint Designer enables information workers and others to add application logic (implemented as a workflow) to SharePoint sites. This is certainly a useful goal, but Microsoft SharePoint Designer also addresses another important problem. If a developer creates a workflow by using Visual Studio, that workflow must be deployed on a server running SharePoint Foundation like any other feature. Yet many SharePoint administrators won’t allow arbitrary code to be deployed on their servers, believing that the risk of destabilizing the system is too great. Being able to create straightforward business logic tied to documents and list items is very useful, however, and it’s something that many SharePoint users need. Along with allowing less technical people to create workflows, Microsoft SharePoint Designer also addresses this problem by providing a safer way to define and deploy business logic on servers running SharePoint Foundation.

The workflow scenarios that Microsoft SharePoint Designer is intended to address are different in some ways from those addressed by Visual Studio and WF Workflow Designer. While it’s certainly possible to create complex applications, the intent of Microsoft SharePoint Designer is to let users add business logic to SharePoint sites. For example, suppose that a site contains a list that allows its users to submit change requests. Microsoft SharePoint Designer could be used to create a workflow that automatically informs the submitter when her change request is accepted or rejected. Similarly, a custom workflow might inform a particular group of users whenever a new document is added to a particular document library. Performing this kind of custom notification isn’t complicated—creating the workflows is easy—but it’s challenging with earlier versions of SharePoint Foundation because of administrators’ reluctance to install user-written code.

There’s an obvious question here: why should logic created with Microsoft SharePoint Designer be treated any differently? What makes SharePoint administrators willing to allow workflows built with this tool to be deployed on the systems for which they’re responsible? The answer is that workflows built with Microsoft SharePoint Designer can only use activities from an administrator-controlled list. In addition to the activities provided by SharePoint Foundation, a site administrator can choose whether to include custom activities created by a developer on this list. By defining exactly what workflows are allowed to do, a SharePoint administrator can have more confidence that deploying logic created by using Microsoft SharePoint Designer won’t destabilize his system.

Both because it’s intended for information workers rather than developers and because it emphasizes simpler scenarios, Microsoft SharePoint Designer uses a different model for creating workflows than the Visual Studio-hosted WF Workflow Designer. Instead of a graphical approach, Microsoft SharePoint Designer uses a rule-based approach. It’s somewhat similar to the Rules Wizard in Microsoft Outlook, a tool that’s familiar to many people. The screen below illustrates how a user of Microsoft SharePoint Designer defines a step in a workflow. Notice that this workflow runs some actions in parallel; some actions run serially. Earlier versions of SharePoint Foundation supported running actions only serially; actions only ran consecutively.

Process Order Workflow

Each step can have a condition and an action. The condition determines whether this step’s action should be executed, as in the If statement shown above. The choices for actions include things such as assigning an entertainer to an event, collecting approval, and many more. Each of these actions is actually carried out by some SharePoint Foundation activity, and the activities used here are the same as with Visual Studio and WF Workflow Designer. The list of actions can also include any other activities allowed by the SharePoint administrator for this site, including custom activities created by developers.

Even though its user interface looks quite different from the graphical approach used with Visual Studio and WF Workflow Designer, Microsoft SharePoint Designer creates a standard WF workflow. What’s actually produced is a workflow that is sequential, parallel, or combination of both with conditions expressed using the WF rules engine. Workflows created with this tool do have some limitations, however. For example, they can’t be modified while they’re running, unlike those built using Visual Studio and WF Workflow Designer, and only sequential and parallel workflows can be created—state machines aren’t supported. Also, workflows built with this tool can be authored against a specific document library, list, or site when they’re designed. Workflow authors can also create a general workflow template that can be later associated with any library, list, or content type. While this does place limits on how a workflow can be used, it also makes deploying the workflow much simpler. In fact, when a user finishes authoring a workflow with Microsoft SharePoint Designer, the tool provides a one-click deployment of the workflow to the target site, which includes activating the workflow. This is significantly less complicated than the multi-step deployment process required for workflows created using Visual Studio and WF Workflow Designer.

Workflows created by using Microsoft SharePoint Designer can also display customized forms. Rather than require workflow authors to create .aspx pages directly, however, the tool instead generates those pages. The author specifies details about how the generated pages should look, such as what fields they should contain, and Microsoft SharePoint Designer takes care of the rest. Of the four points in a workflow’s lifecycle where forms can be used, however, only two are used with workflows created by using Microsoft SharePoint Designer: Initiation and Task Completion. Because every workflow created with this tool must be associated with a particular document library, list, content type, or site there’s no need for an association step and hence no Association form. And since these workflows can’t be modified while they’re running, there’s no need for a Modification form.

Microsoft SharePoint Designer also provides the ability to import workflows that were created using Microsoft Visio 2010. This enables business managers or workflow authors to create the workflow logic using a well known graphical environment. A workflow author can then import the workflow logic into Microsoft SharePoint Designer, modify it if necessary, and then publish it to a SharePoint site.

SharePoint Foundation provides a great deal of functionality for creating document-oriented workflows. Yet ultimately, it’s a platform for development and execution. On its own, it provides no workflow functionality that’s directly usable by end users. Workflows running on SharePoint Foundation also have other restrictions, such as the inability to interact with participants by using Office client applications.

Authoring tool comparison

The following table shows the important differences between the tools that Microsoft supports for creating workflows in SharePoint Foundation by using both SharePoint Designer and WF Workflow Designer in Visual Studio 2010 Professional Edition.