New book: Inside Microsoft SharePoint 2010

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.

Chapter 11

Creating and Developing 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.

What Is Workflow?

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.

Tasks

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.

Lists/Libraries and Content Types

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.

Document Sets

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.

Sites

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

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.”

Visual Studio 2010

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.

Visio 2010

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

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.

The User Experience in a SharePoint Workflow

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.

Creating Custom Workflows

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.”

SharePoint Designer 2010

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.