We’re excited to announce that Ted Pattison, Andrew Connell, Scot Hillier, and David Mann’s Inside Microsoft SharePoint 2010 (ISBN 9780735627468; 620 pages) is now available for purchase!
You can find the book’s introduction in this previous post.
In today’s post, please enjoy an excerpt from Chapter 11, “Creating and Developing Workflows,” which shows you how Microsoft SharePoint 2010 supports automating business processes using workflows.
This chapter explains how Microsoft SharePoint 2010 supports automating business processes using workflows. SharePoint Server 2010 provides several standard workflows that can be used in a variety of business scenarios. SharePoint 2010 also provides you with the ability to create custom workflows with SharePoint Designer 2010. This is what we will discuss in the first half of the chapter. While the strategy of creating custom workflows with SharePoint Designer is recommended for most environments, you might find yourself in a scenario that calls for more control and power. In the second half of this chapter, we will examine developing custom workflow components with Microsoft Visual Studio 2010. As you will see, you can develop custom workflow actions in Visual Studio 2010 that can be used in custom workflows created with SharePoint Designer 2010. Alternatively, you can develop custom workflow templates with Visual Studio 2010 that can be deployed and put to use without any involvement from SharePoint Designer 2010.
In a generic sense, workflow is a business process; it doesn’t even have to be an automated process. It’s just the definition of how business works for one particular area or concern. Printing out a timesheet, handing it to your manager to sign, and then delivering it to Human Resources for payment processing is a workflow, even though it is an entirely manual process. For all intents and purposes, however, when you talk about workflow, you are talking about a business process that has been automated to some degree, and the term workflow typically refers to that automation. All of the following are examples of workflows: ■ A manufacturing assembly line ■ Credit card approval authorization ■ Setup and orientation of a new employee ■ Document review For our purposes in SharePoint, we really don’t care about the first two—they are not what SharePoint does. The second two, however, are very much within the purview of SharePoint. Why is that? What is it about the first two that make them not applicable to SharePoint, and what is it about the second two that makes them pertinent? The answer is us: people. The first two activities do not involve human interaction, while the second two do. Yes, credit card authorization could involve people in special cases, but that is not typical processing. That is known as edge-case exception processing; it kicks in when the primary process can’t handle the situation, and at that point, it may involve people and may even involve SharePoint in some way. The second two examples involve people almost exclusively. They may involve some automated processing for things like spell-checking, but that is just a part of the overall process. For the most part, examples such as processing the paperwork for a new hire or reviewing a document is people interacting with their content, and that is what makes them relevant to SharePoint. SharePoint is a people-oriented tool; it’s all about people interacting with their content, so it makes perfect sense that this carries through into workflow. Therefore, a definition of SharePoint workflow could be The automated process supporting the interactions between people and their content, typically for the purposes of review, modification, and/or publication, relying primarily upon SharePoint Foundation for supporting functionality, such as storage, security, management, and notification. But what does that somewhat sterile definition of SharePoint workflow tell us? How does it help us understand how to support workflow in our environment? It doesn’t, in a sense, but it does point to some important aspects of SharePoint workflow: ■ SharePoint workflows live inside SharePoint. This may sound obvious, but read the definition again and you’ll see that it really says “relying primarily upon . . . ” In other words, it is perfectly all right for non-SharePoint elements to be involved in the process, but SharePoint is the primary actor. This might mean, for example, that notifications are sent out via e-mail or text message, but the content is stored in SharePoint. Or it might mean that a third party translation engine is used to translate content that is stored in SharePoint. ■ SharePoint workflows are human-centric. There will almost always be some machine-to-machine communication or interaction, but people play a key role in SharePoint workflows. ■ SharePoint workflows are tasked with supporting certain types of processes, those related to “review, modification and/or publication” of content. Can SharePoint support other types of processes? Absolutely. But most of the time, the processes that are good candidates for SharePoint workflows will fall into one of these three buckets. ■ SharePoint Foundation provides the plumbing. The definition given previously uses the examples of storage, security, management, and notification, but it is SharePoint Foundation that provides the majority of these types of services. What Is Workflow? 3 SharePoint Workflow Fundamentals Now that we have a general sense of what makes a good SharePoint workflow, let’s take a high-level look at how SharePoint is going to allow us to support that process. The following elements come into play when working with workflow in SharePoint 2010.
The primary interaction point between people and their content inside a workflow is the standard SharePoint Task. At points in the process where human interaction is required, someone needs to be told that he or she has work to do, and that notification is typically done via tasks, as shown in Figure 11-1.
Figure 11-1 A task informs users about assigned work. Tasks allow users to see what work they need to do, track the status of the work, assign the work to someone else, and other related actions. They also serve as a gatekeeper for SharePoint in the sense that the workflow can be stopped until the task is completed—either by the assigned person or through some type of defined escalation or reassignment process, which causes the task to be marked as completed (even if what really happens is that the task is simply closed) and the workflow is ended.
Workflows must be attached to a container. In SharePoint 2007, the only containers available were Lists/Libraries or Content Types. The container owns the workflow, and instances of the workflow run against objects in that container. While this has changed in SharePoint 2010, workflows are still attached to a List, Library, or Content Type the vast majority of times.
While technically, Document Sets in SharePoint 2010 are Content Types, they are important enough to be handled individually. A Document Set is a collection of related documents. It is possible to attach a workflow to a Document Set and have the workflow operate on all the individual documents in the set.
In SharePoint 2010, a workflow can be owned by a site and run against either the site itself or anything within that site. While this is a significant new capability that is the only valid solution in some situations, it is also an edge case. Attaching workflows to sites is not typically how workflows are handled in SharePoint.
SharePoint Designer (SPD) is one of two tools used to build SharePoint workflows. The tool is targeted at administrators and power users, not developers. That is not to say that developers won’t use the tool. In many ways, SPD is the tool used to build workflows in SharePoint 2010. This is a significant change from 2007 and will be discussed later in this chapter, in the section entitled “Creating Custom Workflows.”
In the cases where SPD cannot be used to build a workflow, Visual Studio is the other tool that can be used in the situation. Visual Studio can also be used to extend the capabilities of SPD by introducing custom functionality.
While technically, Microsoft Visio does not create a SharePoint workflow, it is a third tool that becomes involved. Visio Premium now includes the ability to design a workflow in such a way that it can be imported into SPD and finished off. In this sense, Visio is a tool that makes up a part of the SharePoint workflow building continuum. Designing a workflow in Visio is covered later in this chapter, in the section entitled “Creating a Workflow with Visio and SharePoint Designer.”
Windows Workflow Foundation (WF) is not a part of SharePoint; it is a core element of the Microsoft .NET Framework. However, it is still an important part of SharePoint workflows because it is the foundation upon which SharePoint workflow is based. WF provides a set of core objects and services to support the automation of business processes. It does not, however, provide any type of user interface, management, or monitoring. It is a toolkit with which to build business process automation functionality into an application, which is exactly what the SharePoint team did—it used the WF components to build workflow support into SharePoint.
Users have multiple points of interaction with SharePoint workflows. Understanding their experience requires reviewing the various situations in which a user can be involved in a SharePoint workflow. The first time many SharePoint users will experience a SharePoint workflow is when a task is assigned to them as part of a workflow process. In this situation, they will see a screen similar to that shown in Figure 11-1, earlier in this chapter. The example shown in Figure 11-1 shows a task assigned by an instance of the out-of-thebox Approval—SharePoint 2010 workflow template. It offers the opportunity for users to enter a comment and then take one of five actions: ■ Approve Confirms that the document or item the workflow is running on meets the criteria for acceptance. ■ Reject Confirms that the document or item the workflow is running on does not meet the criteria for acceptance. ■ Cancel Closes the task form without recording any action. ■ Request Change Asks that the owner of the document or item makes a modification before they can approve it. ■ Reassign Task Makes someone else responsible for completing the task. The details of any task form will vary depending upon which workflow template the workflow is based upon and how the workflow template was built, but most tasks will be similar to Figure 11-1. If the user has the SharePoint Task list configured to synchronize with Microsoft Outlook, their first workflow experience may still be with a task, but that experience would be with an Outlook task form rather than a SharePoint task form. Other ways with which users can interact with workflows include the following: ■ Starting a new workflow (as shown in Figure 11-2).
Figure 11-2 Users can select from multiple available workflow templates when creating a new workflow instance. ■ Checking the status of a running workflow (as shown in Figure 11-3).
Figure 11-3 The workflow status page shows information about a specific instance of a workflow. ■ Creating a new workflow association (as shown in Figure 11-4).
Figure 11-4 Creating a new workflow association makes it possible to create an instance of the workflow on an item.
While it may be a minor point that is easy to miss, it is important to note that this section is entitled “Creating Custom Workflows,” not “Developing Custom Workflows.” In this section, we are not going to discuss anything that involves development, code, or anything to do with Visual Studio 2010. None of the techniques discussed here require any development experience; they can be performed by an administrator or a trained user. Coded workflows are covered later in this chapter, in the section entitled “Developing Custom Workflow Components.”
The tool of choice for creating new workflows in SharePoint 2010 is SPD. SPD is not a developer tool; it is a user and administrator tool. You don’t use it to write code—you use it to configure SharePoint. SPD has existed since the release of SharePoint 2007—and even before that if you count its prior life as Microsoft FrontPage. While SPD had been tarred with a bad reputation in the past, it has overcome that in the current release. SharePoint Designer 2010 has come into its own and become the premier tool for non-developers to use to customize their SharePoint environment. Used properly, and for tasks for which it was designed, SPD is a great tool.