Flux de travail dans Windows SharePoint Services : scénario

Mise à jour : 2009-02-26

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, perhaps adding comments to explain their decisions. Reflecting this popularity, the example here shows how an approval workflow implemented using Windows SharePoint Services might look. Before walking through this example, it’s useful to define the roles played by different people. Those roles include:

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

• Windows SharePoint Services administrator: the person who installs a workflow template and associates it with a document library or list.

• Workflow initiator: the person who starts a running workflow, causing a workflow instance to be created from a particular workflow template.

• Workflow participants: the people who interact with a workflow instance to carry out the business process it supports.

As described next, individuals in each of these roles have their own parts to play in creating, installing, instantiating, and using a workflow.

Authoring a Workflow

Microsoft provides two options for creating workflows that target Windows SharePoint Services. Developers use Visual Studio 2005 and WF Workflow Designer, while information workers use the simpler rules-based approach provided by Office SharePoint Designer. In both cases, the result is a workflow template that must be deployed to a server running Windows SharePoint Services. Workflow authoring is described in more detail later in this paper, so for now, this scenario assumes that a template has already been created.

Associating a Workflow with a Document Library or List

Before it can be used, a workflow template must be installed on a Windows SharePoint Services system, then associated with a particular document library, list, or content type. After this is done, the workflow can be started from any document or item in that library or list. Workflows operate in the same way on items and documents, and so a workflow template can typically be attached to either (although it’s possible to create a template that can be associated only with an item or only with a document). And while workflows can’t be explicitly started from content types, a workflow associated with a content type can be started from a document or list item to which that content type has been attached.

Both installation and association are done automatically for workflows created using Office SharePoint Designer. For those created using WF Workflow Designer and Visual Studio, however, a Windows SharePoint Services server administrator must explicitly install the workflow template. Once this is done, the template must be associated with a library, list, or content type, something that can be performed by someone with lesser permissions than a server administrator. Whoever creates this association also assigns it a unique name, allowing it to be referenced by users. Optionally, the workflow’s author can let the person who creates the association set options for the workflow’s behavior, such as specifying a default list of people who should always participate in the process. The same template can be associated with multiple libraries, lists, or content types, with each association customized as required. After the association has been created and any options set, a workflow initiator can create a workflow instance from this association, as described next.

Starting a Workflow

Windows SharePoint Services provides three options for creating a workflow instance. All three run the workflow from the beginning every time. (In fact, if a workflow instance created from a particular association is currently running, it’s not possible to create another instance from that same association.) The choices are:

• The workflow can be started manually by a Windows SharePoint Services user.

• The workflow can be configured to run automatically when a document or item is changed.

• The workflow can be configured to run automatically when a document or item is created. For example, a Microsoft Word user might save a new document into a site’s document library, thereby causing an instance of a workflow associated with that library to be executed. A workflow initiator can use Microsoft Word 2007 or older versions to do this. It’s even possible to start workflows in this way from non-Microsoft applications.

This scenario uses the first of these three options: starting a workflow manually. The screen below shows how a document in a document library can appear to a Windows SharePoint Services user. To start a workflow instance from this document, the user clicks on the document and chooses Workflows from the menu.

Making this selection brings up the following screen:

Under the heading Start a New Workflow appear the names of all workflows that can be started from this document. In this example, there are two choices—Approval and Collect Feedback—but if an administrator has associated other workflow templates with this document library, their names would also appear. In this example, the initiator selects Approval, and this screen appears:

Unlike all of the screens shown so far, the contents of this one are defined by the workflow itself. When a workflow is started (i.e., when a workflow instance is created), it can optionally display a screen that allows its user to specify relevant information. For the Approval workflow shown here, this information includes the name of each person who should approve this document, an indication of when each approval is due, and a list of people who should be notified. Once this information has been supplied, the user clicks the Start button in the lower-right corner of this screen. The workflow will now begin executing, requesting that each participant review this document in the order in which their names were entered on this screen.

When a workflow is started, it can also optionally send an email message to the person who started it. Similarly, a workflow can inform its creator by email when it has completed. In this example, for instance, the Approval workflow might send mail to its creator informing her when the approval process is complete. It’s also possible for the participants in the workflow—in this example, the people who are approving the document—to be notified via email that the workflow has something for them to do.

Interacting with a Workflow

Interaction between a person and a running workflow is modeled using the notion of tasks. A task is a unit of work that’s assigned to some individual. In this example, each person on this workflow’s approval list will be assigned a task requesting approval of the document. Windows SharePoint Services maintains a task list for every site, and a running workflow can add tasks to this list, specifying who each task is for. Each user of that site can see what work is waiting for him either by accessing his task list via a Web browser or by synchronizing this site’s task list with his Outlook 2007 task list The screen below shows how browser access to the task list looks for one of the people assigned to approve the document used in this example.

To a Windows SharePoint Services user, his list of waiting tasks is just another list. In the screen shown above, the user has selected the Tasks list from the options visible on the left side of the screen. The only task that’s currently in the list is a request to approve the document. (The document itself is accessible through the Link that appears on the right side of the screen.) To work on the task, the user in this example clicks on the task name, bringing up this screen:

How a workflow interacts with participants can vary, and so this screen is defined by the workflow itself. In this example, the participant is provided with a field for comments along with buttons to approve or reject the document. Other options are also available, letting him reassign the task to another person or request a change. Here, the user might enter a comment, then click the Approve button. The workflow will then create a task in the task list of the next person in its list of approvers. Once every participant has responded, the workflow ends.

Windows SharePoint Services workflows also provide other options, including the following:

• A workflow’s initiator can check its status. In the scenario described here, for instance, she might check to see how far the approval process has gotten.

• A workflow can be modified while it’s executing. What modifications are allowed, if any, is determined by the workflow’s author. An approval workflow, for instance, might allow adding a new approver while the workflow is in progress. The ability to modify in-flight workflows is important, as it’s a reflection of how people actually work. Spontaneous change to business processes is an inescapable reality, and so Windows SharePoint Services workflows provide a way to handle this.

Summarizing the Process

There are plenty of moving parts in a Windows SharePoint Services workflow. The figure below gives an overall view of how the process works.

To summarize: Once a workflow template has been installed and associated with a document library, list, or content type, a step not shown here, a user of that site can create an instance of this workflow. The process begins with the workflow initiator selecting a document and an associated workflow template (step 1). The initiator creates a workflow instance from this association (step 2), then customizes this new instance and starts it (step 3).

Next, the running workflow instance adds a task to the task list of a participant (step 4). (The approval workflow used in this scenario assigns these tasks sequentially, but it’s also possible for a workflow to assign tasks to many participants at once, letting them all be carried out in parallel.) Participants in the workflow can learn about tasks the workflow assigns to them by checking their task list (step 5). Each participant then interacts with the running workflow instance to complete this task (step 6). In the example described here, this required approving a document, but it could be anything the workflow author chooses.

It’s worth noting that the document a workflow is running on 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’s no requirement that the workflow make any use of the document or item with which it’s associated. Another point worth emphasizing is that what a workflow’s initiator and participants see in steps 1, 2, and 5 is defined by Windows SharePoint Services itself. The forms used in step 3 and step 6, however, are defined by the workflow author. This allows the author to control how users customize and interact with the workflow.

Along with providing a platform for creating human workflow applications, Version 3.0 of Windows SharePoint Services also provides a pre-defined Issue Tracking workflow that can be used as-is by end users. This workflow allows assigning active issues to participants and tracking those issues. Once created, an issue can be moved first to a Resolved state, indicating that it’s been handled by the responsible workflow participant, then to a Closed state, indicating that the workflow initiator has accepted the resolution and closed the issue.

Understanding the basics of how people use workflows in Windows SharePoint Services is an essential part of grasping this technology. Yet it’s also useful to know something about how a workflow author creates those workflows. The next section looks at the two approaches available for doing this.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

• Plan Sites and Features, Part 1

See the full list of available books at Downloadable content for Office SharePoint Server 2007.