Approval Workflow: A Scenario (SharePoint Server 2010)
Applies to: SharePoint Server 2010, SharePoint Foundation 2010
Topic Last Modified: 2011-09-28
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 Server 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 Server 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.
Microsoft provides two options for creating workflows in SharePoint Server 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 Server 2010. This scenario assumes that a workflow template has already been created.
Before you can use a workflow, you must install a workflow template on a server that is running SharePoint Server 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.
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 Server 2010)
SharePoint Server 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 Server 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 Server 2010 user does the following:
Points to the document and selects Workflows from the drop-down menu or ribbon.
Selects the workflow to start.
For example, for a document in a document library, only two choices are ordinarily available — Approval and Collect Feedback. If an administrator has associated other workflow templates with this document library, the names of those workflow templates also appear.
Note The predefined Approval and Collect Feedback workflows are available only in SharePoint Server 2010.
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 an Approval workflow, this information includes 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.
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 Server 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.
|If you are running SharePoint Server 2010, users can synchronize the site’s task list to their Microsoft Outlook task list.|
To a SharePoint Server 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 Server 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 Server 2010 workflows were designed to let users handle this.
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.
The process starts when the workflow initiator selects a document and starts an instance of a workflow.
The initiator creates a workflow instance from this association.
The user customizes this new instance and starts it.
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.
Participants in the workflow can learn about tasks that the workflow has assigned to them by checking their task lists.
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 Server 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 the forms that are used in step 6. This allows the author to control how users customize and interact with the workflow.
Together with a platform for creating human workflow applications, SharePoint Server 2010 provides a predefined Issue Tracking workflow. This Three-state workflow allows for assigning active issues to participants and tracking those issues. Once created, an issue can be moved from an Active state to a Resolved state, which indicates that the responsible workflow participant has handled it, and then to a Closed state, which indicates that the workflow initiator has accepted the resolution and closed the issue.
The following section describes a scenario using the predefined Approval workflow in SharePoint Server 2010.
The workflow described in this section is the predefined Approval workflow provided with SharePoint Server 2010. All user interaction with the workflow happens by using InfoPath Forms Services workflow forms that are displayed in applications in the Microsoft Office system.
The process starts when the workflow is associated with a document library or list. The workflow initiator creates a running workflow instance. This can be done from SharePoint Server 2010 or can be done directly from a Microsoft Word document.
When a user clicks the Start link for the Approval workflow, the workflow begins and opens a InfoPath Forms Services workflow form. The predefined Approval workflow enables its initiator to customize its behavior by specifying a list of approvers, setting how long each one has to perform his task, and so on.
The people who are listed as approvers in this workflow are each sent an e-mail message in the order in which their names were entered.
The approver can examine the document by clicking the document name link in the body of the e-mail message.
In this scenario, the content of the workflow’s Task Completion form is defined as an InfoPath Forms Services workflow form and is displayed directly in Microsoft Outlook. The approver can add comments, and then approve or reject the document.