C H A P T E R  12

Automating with Workflows

SharePoint Server 2010 contains a powerful workflow engine based on the .NET Framework's Workflow Foundation. Using SharePoint Designer, you can leverage this engine to automate many business processes quickly and easily.

In this chapter, you will explore the concepts and tools used to build and customize workflows in SharePoint Designer 2010. You will begin with the basic ideas behind the workflow engine. Then, you will learn about the components that are available to create new workflows. Finally, you will go through a series of exercises designed to touch on the most important use cases, where workflows can add value to a SharePoint solution.

You will learn about the following topics in this chapter:

• Using the concepts and building blocks available within SharePoint Designer to automate processes with workflows
• Using mechanisms to control security in workflows
• Understanding the collection and storage of data within a workflow instance
• Creating flexible, reusable workflow definitions
• Customizing the built-in workflows that come with SharePoint Server 2010
• Customizing the end-user experience by using InfoPath forms
• Creating all-new workflows with SharePoint Designer
• Automating SharePoint maintenance with site workflows

Introduction to Workflow

With version 3.0 of the .NET Framework, Microsoft introduced a standard infrastructure for creating and hosting custom business processes called the Windows Workflow Foundation (WF). WF is a set of libraries that contain a complete in-process workflow engine and associated classes. The workflow engine manages the instances of a workflow that are running within the process.

Figure 12-1. Windows Workflow Foundation in the .NET stack

Although the engine is designed to be hosted within any .NET application, SharePoint Server 2010 provides a wide variety of tools for designing, deploying, and managing workflows within a SharePoint server farm. Workflows are defined by using a designer, typically either SharePoint Designer 2010 or Visual Studio 2010. The workflow definition is then deployed to the SharePoint environment and associated with a list, a content type, or a site. An instance of the workflow may be started based on the creation of a document, a manual action, or the action of a program.

A workflow running in SharePoint has access to many of SharePoint's resources and can perform actions such as checking files in and out, creating or moving list items, setting item permissions, and so on. The most common actions taken by workflows are to send e-mail notifications and to assign tasks to users. SharePoint maintains the state of the workflows and provides the interface for managing instances. SharePoint also maintains a detailed log of all workflow actions and results.

As stated earlier, the tools most commonly used to create workflows in SharePoint are SharePoint Designer and Visual Studio. SharePoint Designer places certain restrictions on the types of workflows that can be created. For example, SharePoint Designer does not support custom .NET code, looping constructs, or state machine workflows. Even so, most common business processes can be modeled very well with the workflow features that are available in SharePoint Designer. Those that cannot are generally complex enough that a development team should be engaged to create the best implementation possible. These highly customized workflows should be created through a development tool such as Visual Studio. This chapter focuses on the features available to site designers and power users in SharePoint Designer.

As with other aspects of SharePoint Server, workflow could easily fill its own book, or several of them. To get a more in-depth look at workflow development, see Beginning WF: Windows Workflow in .NET 4.0 by Mark Collins (Apress, 2009) and Pro WF: Windows Workflow in .NET 4.0 by Bruce Bukovics (Apress, 2010).

What's New in SharePoint Designer 2010 Workflows?

In SharePoint Designer 2007, the scenarios available to workflow developers were limited by several barriers that have been removed in SharePoint Designer 2010. It is now much easier to create and deploy a wider variety of workflows from entirely within SharePoint Designer. There is far less need to abandon designer-based workflows in favor of Visual Studio. The introduction of the Ribbon menu and improvements to the designer interface have made SharePoint Designer a more productive workflow design environment as well.

Here is a list of some of the more important changes that have been made in the latest release:

• More-flexible workflow definitions
  • Reusable workflows are associated with a content type instead of a specific list.
  • Site workflows are associated with a site and not a specific list or item in a list.
  • SharePoint's out-of-the-box workflows can now be customized by using SharePoint Designer.
  • Association columns can be defined in a workflow and are automatically added to a list that uses the workflow.
  • Solution files (WSP) can be generated by exporting a workflow through SharePoint Designer. These can then be imported into another farm.
  • InfoPath forms are generated by SharePoint Designer for association, initiation, and task forms. These forms can be customized by using InfoPath Designer.
• Workflow step and action improvements
  • Parallel blocks allow the workflow designer to create multiple simultaneous paths through the workflow instead of all steps occurring in a strict sequence.
  • Nested steps allow for more-sophisticated workflow structures.
  • Document set actions can be used to control a document set and the documents within it as a unit.
  • Impersonation steps enable workflows to manage security permissions on list items by using the credentials of the workflow author instead of the user who started the workflow.
  • Set Workflow Status is a new action that allows the workflow designer to set an arbitrary status string for the workflow.
  • The Task Process action supports the creation of complex task sequences with rules for completing and continuing a series of tasks within a workflow.
  • Start Approval Process and Start Feedback Process are customized instances of the Task Process action that implement the standard approval and feedback workflows. These actions allow the default workflows to be customized.
• Improved workflow visualization

Microsoft Visio 2010 can now be used to create the overall structure of a workflow. That structure can then be imported into SharePoint Designer for implementation.

The Workflow Status page can contain a visual representation of the current state of a running workflow in a Visio diagram embedded in the page.

Workflow Concepts

In this section, you will explore the concepts on which SharePoint workflows are built. You will start by looking the security context of your workflows. Then you will look at the different types of workflows that SharePoint can host. A workflow instance contains various data elements and often has forms associated with it that provide an interface for data entry. Finally, you will learn about the tools available to create and customize workflow definitions, with an emphasis on choosing the right tool for the job.

Security

When a user starts a workflow instance, either intentionally or as a side effect to some other action, that instance will execute using that user's credentials. Even if the workflow continues to run long after the user has left the site, the workflow engine will still use those credentials. Any permissions (such as file or list item access rights) associated with the initiating user will be applied to the instance when it is running.

This security context has often proven too restrictive for some proposed workflow designs. For example, say a user creates a vacation request and saves it in a document library. As a result, an approval workflow is started. Once the request is approved, you want to move it into a protected archive for approved requests. Because the user who initiated the workflow doesn't have access to the protected archive, the workflow can't move the request into it.

One of the most important workflow improvements in SharePoint 2010 was created specifically to deal with this type of situation. A new type of workflow step, called an impersonation step, can be added to a workflow just like any other step. The difference is that the security context for the impersonation step is not that of the initiating user but of the workflow's author. The workflow's author is generally the user who last updated the workflow's definition. That user can be given the necessary permissions to perform the needed actions that the initiator may lack.

An impersonation step can contain conditions and actions like any other step, but the following set of actions can appear only within an impersonation step:

• Add List Item Permissions
• Remove List Item Permissions
• Replace List Item Permissions
• Inherit List Item Parent Permissions

These actions are designed to provide the workflow designer with greater flexibility when working with items and document permission settings. This enables SharePoint Designer to create workflows that have far more sophisticated security requirements.

Types of Workflows

One of the most common reasons for not using SharePoint Designer 2007 for building workflows had to do with way designer workflows were associated with lists. When designing a workflow, the user had to identify the one unique SharePoint list with which the workflow was to be associated. This was useful in that it gave the workflow access to all of the fields associated with the list, but it made it impossible to reuse workflow definitions between lists. Creating a list-independent workflow definition required Visual Studio.

In SharePoint Designer 2010, the site designer can create a list workflow as described in the preceding paragraph or a reusable workflow that is not tied to a specific list. Instead, a reusable workflow is designed using a SharePoint content type. The content type acts as a template for the eventual list item that will be associated with an instance of the workflow. Because content types inherit from one another, a workflow designed for one content type can also be used for any content type that is derived from it. Because all list and library items in SharePoint ultimately derive from the Item content type (called All in the SharePoint Designer interface), a workflow designed against that type can be used with any list or library item.

Reusable workflows can also be configured as part of the content type's definition. Whenever the content type is used in a SharePoint list, the workflow is automatically configured. This is a powerful means of standardizing processes across your SharePoint farm, because content types can also be shared between site collections in SharePoint Server 2010.

Another useful new type of workflow in SharePoint 2010 is the site workflow. In SharePoint 2007, all workflows had to be associated with a list or library item. What if the workflow process you are automating doesn't naturally correspond to a single content item in the site? In the previous release of SharePoint, this meant that a document or list item had to be created just to allow the execution of a workflow.

Figure 12-2. Workflow instances in SharePoint

A site workflow definition runs at the site level, so it has no current item associated with it. However, a site workflow is a normal workflow in most other respects. It can create list items, check files in or out, send e-mails, and take any other action that does not require an associated list item.

Workflow Context Data

A workflow instance stores data that controls the processing of the workflow. There are several classifications of this data, depending on how it came to be associated with the workflow. Together, the data and status information for a workflow instance is referred to as its context. Most actions within a workflow have parameters that can be set by using values from the workflow context.

The workflow context contains status values related to the running of the instance. These include the current status of the workflow, when the workflow was started, and which user initiated the workflow. These values are set automatically by the workflow engine and can be used throughout the workflow.

Workflow parameters are data elements that are declared in the workflow definition and are passed into the workflow at startup. Parameters can be defined to receive their value at association or initiation. Association refers to the point in time when the workflow definition is associated with a SharePoint list. Association parameters can be thought of as configuration values for a workflow. Initiation parameters are set when the workflow instance is started manually in a SharePoint web site. A parameter can be defined as both an association and an initiation parameter. In this case, the association parameter setting becomes a default for the initiation parameter, which can then be overridden by the user starting the workflow. To create a parameter for a workflow that cannot be changed by the initiator, it should be created as an association-only parameter. Because site workflows are not associated with SharePoint lists, they do not have association parameters, only initiation parameters.

In a list or reusable workflow, the context contains a reference to the list item associated with the workflow instance. This item is called Current Item within SharePoint Designer. This object gives the workflow the ability to read and write the field values for the list item. For a list workflow, the current item contains all of the item's fields. For a reusable workflow, the current item contains the fields that are part of the associated content type. There is no current item for a site workflow.

A special type of column on the current item is called an association column. An association column is declared in the workflow definition just like a parameter, but instead of being passed into or out of the workflow, it is part of the current list item. When a workflow definition is associated with a list, SharePoint checks to ensure that each of the workflow's association columns is present in the list. If not, a new column is automatically created for the association column. Association columns can be read and written in the same way as any other column, by using the Current Item object.

The final data elements in the workflow context are workflow variables. These are simple variables that store data throughout the lifetime of the workflow. They can be dates, strings, numbers, Boolean values, or list item IDs. These values are retained until the workflow terminates. They are used to store transient data that will not be needed after the workflow completes.

Workflow Forms

During the execution of a workflow, SharePoint often needs to collect information from a user. To accomplish this, a form is rendered on the web site that collects the data and adds it to the workflow's context. There are three types of workflow forms distinguished by the workflow action that causes them to be displayed:

• Association forms are displayed when the workflow definition is attached to a SharePoint list. This form collects the values of the workflow's association parameters.
• Initiation forms are displayed when a user manually starts a workflow instance. This form collects initiation parameters.
• Task forms are designed to collect data during the processing of a workflow task. The data collected is generally written to the current item, to the History list, or to a workflow variable.

Workflow forms can be implemented in a variety of ways but, historically, the most popular types have been ASP.NET and InfoPath forms. In the past, ASP.NET forms have held two big advantages. First, many developers are more familiar with ASP.NET development than InfoPath development. Second, InfoPath has imposed restrictions with regards to security and the edition of the SharePoint server product required.

In SharePoint 2010, InfoPath forms are much easier to use because of automated form generation and sandboxing. Sandboxing, described in Chapter 11, involves the ability to execute .NET Framework code within a secure InfoPath form template.

SharePoint Designer 2010 makes using InfoPath forms almost trivially easy. When you create a workflow in SharePoint Designer, you declare the association and initiation parameters along with the data for each type of task. SharePoint Designer automatically creates basic InfoPath data entry forms for entering this data, as shown in Figure 12-3. As you will see in a later exercise, the workflow designer can open these form templates in InfoPath Designer and customize them as needed.

Figure 12-3. Workflow Forms list in SharePoint Designer

Workflow Components

SharePoint Designer 2010 workflows are built from a set of basic building blocks. Although these components seem quite simple at first, they provide a wide range of options for managing data and processes.

Steps

All workflows created in SharePoint Designer 2010 are known as sequential workflows in Windows Workflow Foundation parlance. This means that they are structured as a series of steps that are executed in sequence. Branching logic is limited to if-then-else conditions, and looping is not supported. If looping or advanced flow control logic (for example, a State Machine workflow) is needed, the workflow will need to be constructed using Visual Studio.

When a new workflow is created, a single step is added to the work surface. A workflow must always contain at least one step. Additional step objects are added to the workflow by using the Step button in the Insert group of the menu bar, as shown in Figure 12-4. Objects will always be inserted at the point designated by the flashing orange cursor. This cursor can be moved by clicking another location on the workflow design surface.

Figure 12-4. Workflow Designer (initial view)

A new feature in SharePoint Designer 2010 is the ability to create nested steps (see Figure 12-5). The nesting can be as deep and complex as needed.

Figure 12-5. Nested workflow steps

Another useful new feature in SharePoint Designer 2010 allows steps to be executed along multiple simultaneous paths by using the parallel block. The steps or actions within a parallel block will run in parallel with one another, creating two or more independent paths of execution. The workflow will pause at the bottom of the parallel block until all of the blocks inside have completed. Figure 12-6 depicts a parallel block with steps embedded within the block, but any action can be used within a parallel bock, whether enclosed in nested steps or not.

Figure 12-6. A parallel block with embedded steps

The last type of workflow step is new to SharePoint Designer 2010. This is the impersonation step described in the “Security” subsection earlier in this chapter. This type of step executes its actions in the security context of the workflow author instead of the initiator. Impersonation steps are different from other steps in that they do not support nesting or being nested within other steps.

Conditions and Actions

Within the steps of a workflow are a series of conditions and actions. A condition provides the ability to perform conditional branching within the workflow. Actions are components that perform an action on behalf of the workflow initiator.

Conditions can be chained together to create if-then-else logic. Adding additional conditions can also create else-if logic, as shown in Figure 12-7.

Figure 12-7. Conditional blocks

Conditional blocks can be nested inside other conditional blocks, creating sophisticated logical structures.

Action shapes in a workflow represent the work that is to be accomplished by the workflow. See the upcoming section “SharePoint Server Built-In Components” for a complete listing of the actions available within SharePoint Designer. Note also that new actions (a.k.a. custom activities) can be created using Visual Studio and used from within SharePoint Designer workflows.

When an action is added to the workflow design surface, its parameters are rendered as a set of hyperlinks, as shown in Figure 12-8. Clicking one of these parameters will launch an editor specific to that parameter. Most actions have at least one parameter. Many have more than one. Becoming familiar with the parameters and options associated with each available action is the key to creating powerful workflows in SharePoint Designer.

Figure 12-8. Action parameters

SharePoint Server Built-In Components

SharePoint Server 2010 comes with many built-in objects to enable the creation of workflows.

Workflow Definitions

The out-of-the-box workflows can be used as is or they can provide a starting point for creating customized approval processes. These include the following:

• Approval—SharePoint 2010
• Collect Feedback—SharePoint 2010
• Collect Signatures—SharePoint 2010
• Publishing Approval

The first three workflows are updated versions of the workflows that were included in SharePoint Server 2007. The fourth is the enhanced approval process used in SharePoint publishing sites. The Publishing Approval workflow may not be present if the publishing feature is not in use. The difference between these workflows in SharePoint 2010 and their 2007 counterparts is that they can now be copied and customized in SharePoint Designer 2010. Although it is possible to edit the SharePoint-provided versions of these workflow definitions, it is considered a best practice to make a copy and modify the copy.

Actions

SharePoint Designer 2010 comes with a large number of built-in actions that can be used to build most common business processes. When selecting the actions for a workflow, remember that some actions are not available in certain situations.

Many of the available actions are straightforward in their purpose and configuration. However, SharePoint 2010 has introduced a new action called the Task Process action that is a bit different. This action is a container for an entire task-oriented process such as an approval sequence. This action is almost a workflow within a workflow, but it is specifically designed to manage a process consisting of many tasks routed based on a set of rules instead of a simple sequence. The standard Approval, Collect Feedback, and Collect Signatures workflow definitions are all based on a single instance of this action. There is an entire subset of actions, called Task Behavior actions, that are designed to be used within the Task Process action shape.

SharePoint Foundation 2010 is a subset of the functionality that is available in SharePoint Server 2010. Therefore, it is reasonable to expect that the actions available in SharePoint Foundation would be a subset as well. Generally, the actions that are not available in SPF are those that use features that do not exist in that product. For example, the Declare Record action is not available in SPF workflows because record management is a feature of SharePoint Server 2010, not SPF.

Table 12-1 lists the actions that are available out of the box with SharePoint Server 2010. The table indicates which actions are available using SharePoint Foundation 2010, as well as in SharePoint Server 2010, and which are available within site workflows. Remember that site workflows cannot use actions that require a Current Item.

Building Workflows with SharePoint Designer

Now that you have a firm grasp of the concepts behind workflows in SharePoint Designer, let's walk through some real-world examples. In the exercises that follow, you will create and customize workflows by using SharePoint Designer. First, you will customize one of the built-in workflows. After that, you will customize the InfoPath forms generated for that workflow. Then you will create your own reusable workflow from scratch. Finally, you will create and deploy a site workflow.

EXERCISE 12-1. CUSTOMIZE A BUILT-IN WORKFLOW

EXERCISE 12-2. CUSTOMIZE A GENERATED INFOPATH FORM

EXERCISE 12-3. CREATE A REUSABLE WORKFLOW

EXERCISE 12-4. CREATE A SITE WORKFLOW

Site workflows can be used in any situation where a workflow needs to run outside of the context of a list or a specific list item. They can perform all of the same actions as other workflows except for those that manipulate the current item. This makes them useful in many situations that are not elegantly handled with list or reusable workflows.

Summary

In this chapter, you have:

• Explored the tools available within SharePoint Designer for automating processes with workflows
• Explored managing security and data in workflows
• Built a reusable workflow definition
• Customized one of SharePoint's built-in workflows
• Created a new workflow from scratch in SharePoint Designer
• Customized workflow forms by using InfoPath Designer
• Created a site workflow to run outside of any list or library