Approval Workflow: A Scenario (SharePoint Foundation 2010)

  • Article

 

Applies to: SharePoint Foundation 2010

This scenario illustrates how to create, deploy, and use an approval-type workflow.

The most common example of human workflow in most organizations is some variation of approval: A group of people must approve or reject some document, and perhaps add comments to explain their decisions. This article shows how an approval-type workflow that is created in SharePoint Designer 2010 or Workflow Designer in Visual Studio 2010, and that is then hosted by using SharePoint Foundation 2010 might look. Before reading this example, it is useful to define the roles that different people play.

  • Workflow author   The developer or information worker who creates a workflow template.

  • SharePoint Foundation 2010 administrator   The person who installs a workflow template and associates it with a document library or list.

  • Workflow initiator   The person who starts a workflow, causing a workflow instance to be created from a particular workflow association.

  • Workflow participants   The people who interact with a workflow instance to complete the business process that it supports.

As described in the following section, people in each of these roles play their own parts in creating, installing, starting, and using a workflow.

Authoring a workflow

Microsoft provides two options for creating workflows in SharePoint Foundation 2010. Developers use Visual Studio 2010 and Workflow Designer, whereas information workers use the rules-based approach that SharePoint Designer 2010 provides. In both cases, the result is a workflow template that must be deployed to a server that is running SharePoint Foundation 2010. This scenario assumes that a workflow template has already been created.

Associating a workflow

Before you can use a workflow, you must install a workflow template on a server that is running SharePoint Foundation 2010, and then you must associate the workflow with a particular document library, list, content type, or (in the case of a site workflow) site. You can then start the workflow from any document or item in that library or list. Although workflows cannot be explicitly started from content types, a workflow that is associated with a content type can be started from a document or list item to which that content type is attached. Because workflows operate in the same manner on items and documents, a workflow template can typically be attached to a list, library, or content type. You can also create a template that can be associated only with a particular list or library.

Both installation and association are performed automatically for workflows that are deployed by using SharePoint Designer 2010. However, when you use Visual Studio to deploy workflows, a server administrator must explicitly install the workflow template. In addition, a user must associate the template with a library, list, content type, or site. Whoever creates this association also assigns the association a unique name, which enables users to reference it. Optionally, the workflow author can let the person who creates the association set options for the workflow behavior, such as a default list of people who can always participate in the process. The same template can be associated with multiple libraries, lists, or content types, and each association can be customized as required. After the association is created and any available options are set, a workflow initiator can create a workflow instance from this association, as described in the following section.

Associating a workflow with a site

Site workflows are associated with the site itself. An item does not have to be started for the workflow to run.

You can use site workflows for processes that do not have a list item context. For example, you could create a workflow to request permissions for the site, a workflow to request and provision a new site, or a workflow that uses context that is stored outside the SharePoint site, without having to create a corresponding SharePoint list item from which to start the workflow.

Site workflows can be associated with a site through the site’s settings and can be started on the site itself. SharePoint Designer 2010 can also deploy site workflows directly to a site.

Site workflows work in the same way as list items, as described earlier in this article, except that site workflows cannot be started from a document or item in a library or list.

For more information, see Add a workflow association (SharePoint Foundation 2010).

Starting a workflow

SharePoint Foundation 2010 provide three options to start an instance of a workflow. All three options run the workflow from the beginning every time. (If an instance of a workflow that is created from a particular association is already running on a particular document or list item, it is not possible to start another instance of the workflow on the same document or item.) The following are the options for starting a workflow:

  • A SharePoint Foundation 2010 user can manually start a workflow.

  • You can configure a workflow to run automatically when a user creates a document or item.

  • You can configure a workflow to run automatically when a user changes a document or item.

For example, a Microsoft Word user can upload a new document to a site’s document library. This causes an instance of a workflow that is associated with that library to start.

This scenario uses the first of these three options: manually starting an Approval workflow for a document. To start a workflow instance from a document in a document library, a SharePoint Foundation 2010 user does the following:

  1. Points to the document and selects Workflows from the drop-down menu.

  2. Selects the workflow to start.

    This example assumes that a workflow that will route the document for approval has been created.

When a workflow is started (that is, when an instance of a workflow is created), it can also display a screen that enables a user to specify relevant information. For a workflow that routes a document for approval, this information can include the name of each person who must approve the document, an indication of when each approval is due, and a list of people to be notified. After this information is supplied, the user clicks Start. The workflow begins to execute and requests each participant to review the document in the order in which names were entered on this screen.

When a workflow is started, it can also optionally send an e-mail message to the person who started it. Similarly, a workflow can inform its creator by e-mail when it has finished. You can also configure the workflow to notify the participants in the workflow — in this example, the people who are approving the document—by e-mail that the workflow has something for them to do.

Interacting with a workflow

The concept of tasks models the interaction between a person and a running workflow. A task is a unit of work that is assigned to an individual. For example, each person on this workflow’s approval list will be assigned a task that requests approval of the document. SharePoint Foundation 2010 can have a task list for every site, and a running workflow can add tasks to this list that specify the person or persons who are assigned to each task. Users of that site can see the work that is awaiting them by accessing their task list through a Web browser. Optionally, you can have a custom task list for just your workflow tasks.

To a SharePoint Foundation 2010 user, the list of waiting tasks is merely another list. In this example, the user browses to the team SharePoint site and selects the option to view the list of Tasks that are assigned to him. To work on a task, the user in this example clicks the task name.

Because the way that a workflow interacts with participants can vary, the workflow itself defines the screen that is displayed to the user. In this example, the workflow provides options to approve or reject the document and a text box in which participants can type comments.

Other available options let users reassign the task to another person or to request a change. Here, the user might type a comment, and then click Approve. The workflow then creates a task in the task list of the next person in its list of approvers. When every participant has responded, the workflow ends.

SharePoint Foundation 2010 workflows also provide other options, including the following:

  • The initiator of a workflow can check the status of the workflow.

    For example, in the scenario described here, the initiator might check the progress of the approval process.

  • A workflow can be modified while it is executing.

    The workflow’s author determines the allowed modifications, if any. An Approval workflow, for example, could allow the addition of a new approver while the workflow is in progress. The ability to modify in-progress workflows is important because it reflects how people actually work. Because spontaneous change to business processes is a part of life within any business, SharePoint Foundation 2010 workflows were designed to let users handle this.

Summarizing the process

When a workflow template is installed on a site and associated with a document library, list, site, or content type, a site user can start an instance of a workflow.

  1. The process starts when the workflow initiator selects a document and starts an instance of a workflow.

  2. The initiator creates a workflow instance from this association.

  3. The user customizes this new instance and starts it.

  4. The running instance of the workflow adds a task to the task list of a participant.

    The approval workflow that is used in this scenario assigns these tasks sequentially. However, you can assign tasks to many participants at the same time, which allows tasks to be performed in parallel.

  5. Participants in the workflow can learn about tasks that the workflow has assigned to them by checking their task lists.

  6. Each participant interacts with the running instance of the workflow to complete assigned tasks.

    In the example described here, this interaction required approving a document, but the interaction could be anything that the workflow author wants.

It is worth noting that the document on which a workflow runs is not itself sent from person to person. Instead, the document remains on the site, and each workflow participant is given a link to it. In fact, there is no requirement that the workflow use the document or item with which it is associated. Another point worth emphasizing is that SharePoint Foundation 2010 itself defines what is displayed to the initiator of the workflow and the participants in the workflow in steps 1, 2, and 5. However, the workflow author defines and creates the ASPX Web pages that are used in step 3 and step 6. This allows the author to control how users customize and interact with the workflow.