Workflows are provisioned in SharePoint Server 2007 site collections as features and are built on the Windows Workflow Foundation. Each type of workflow includes a custom workflow template specific to the type of workflow activity. For instance, the template that underpins the approval routing workflow includes the ability to assign workflow tasks to all participants at the same time (parallel workflow) or one participant at a time (serial workflow). More advanced workflows, such as a disposition workflow, determine whether a document (item) is deleted (allows the item’s metadata to be retained in the audit log). Workflows are enabled at the site collection level and are consumed within document libraries and lists throughout sites within a site collection. Table 10-2 defines each of the out-of-the-box workflows.
Table 10-2. Out-of-the-box Workflow Overview
Template | Description |
|---|---|
Approval | Routes a document for approval. Approval is often a prerequisite to another document management task, such as publishing a document to a Web site or submitting a business proposal to a client. Authors choose approvers, send instructions, and track workflow status. By default, Approval is a serial workflow, and the order in which approvers view the document is specified by the author. Approvers can approve or reject the approval task or request changes. Approvers cannot modify the document. |
Collect Feedback | Sends a document for review. The author chooses the reviewers, sends instructions, and can check the workflow’s progress. Reviewers receive e-mail notification and are assigned a task with a link to the document to review. Participants can optionally delegate their tasks or decline altogether. Reviewers provide feedback that is compiled and sent to the document owner at the workflow completion. Collect Feedback is a parallel workflow. Reviewers can provide feedback in any order. |
Collect Signatures | Gathers signatures needed to complete the document. The workflow is started from within a Microsoft Office client. Requires that signing documents be enabled on Microsoft Office 2007 applications. |
Disposition Approval | Manages the expiration and retention of documents. Participants decide whether to retain or delete expired documents. |
Three-state | Manages approvals in issues lists, but can also work with other lists and document libraries. In SharePoint Server 2007, this is the only out-of-the-box workflow that is not enabled (active) by default. You need to activate this workflow under the site collection features. |
There is also a special Translation Management workflow template, not listed in Table 10-2, that works with the Translation Management library and manages source documents by creating copies of each document for specified languages. The workflow subsequently assigns tasks to translators so that each separate copy of a document can be translated into defined languages.
During workflow creation, several configuration options are available, including the following:
Designation of a task list and a history list for the workflow. By default, this is the tasks list in sites provisioned from the team site template or the workflow tasks list in sites provisioned from a publishing site template. The workflow history list is selected by default as the history list.
Start options. By default, these options allow users with edit rights to a document library or list to manually start a workflow on an item (or, alternately, to lock down the ability to start a workflow to those users with Manage Lists permissions); start a workflow to approve publishing a major version of an item (enabled only where versioning and content approval is enabled on a document library); start the workflow when a new item is created; and start the workflow whenever the item is changed.
Workflow Tasks. This setting enables you to either assign tasks to participants included in a workflow as serial (one participant at a time) or parallel (all participants simultaneously) and allow workflow participants to reassign a task to another person and request changes before completing the task (for example, request more information or make modifications to a document before it gets approved).
Default Workflow Start Values. Use this setting to add the names of workflow participants (the participant names are added in the order in which you want to assign serial workflow tasks); allow changes to a participant list; enter text for the workflow request; establish due dates for both parallel and serial workflow options; and notify others about the workflow without assigning them tasks (for example, alert a team leader that a project document is currently in a workflow approval process).
Complete The Workflow. Use this setting to define the actions that determine when a workflow is completed (e.g., a certain number of tasks are completed) or canceled (e.g., a document is rejected or changed). Remember that when a workflow is initiated on a document (or item within a document library), that document is not automatically checked out, and other users who are not participants within a workflow can potentially modify the document.
Post-completion Workflow Activities. This gives you the option to update the approval status (use this workflow to control content approval). Note that if you select the Update The Approval Status (Use This Workflow To Control Content Approval) check box but don’t have the document library configured to require approval, then the workflow will generate an error when it runs. An error message such as The task was marked as complete but no approval or rejection was made and a workflow status of Error Occurred will be logged in the workflow history once a workflow task is completed.
Figure 10-2 shows a typical workflow process within SharePoint Server 2007.
Workflow history maintains a record of each step within a workflow, including approvals, disapprovals, updates to a workflow, and workflow errors.
By default, when you create and consume an out-of-the-box workflow or a custom workflow created in SharePoint Designer 2007, an historical record for each workflow is saved to a workflow history list within the site where the workflow is created and/or deployed. The workflow history list is either created when a content type configured with a workflow is added to a document library or when a workflow is directly created on a document library. The workflow history list is not directly visible in the site’s All Site Content list, but you can access the list through a document library’s workflow settings. You can also access the workflow history list in its raw form by directly entering the list URL into the browser address bar. Even if a document library workflow or content type workflow is deleted from a site, the workflow history remains in the site’s designated workflow history list.
When you create an out-of-the-box workflow, part of the workflow configuration process involves designating a workflow history and task list for each workflow. For instance, if you create a new approval workflow on a document library, you have the option of using the default workflow history list or creating a new history list. If you choose to create a new history list, SharePoint will create a new workflow history list and prefix the name of the list with the name of the workflow (for example, ApprovalXYZ History). The same applies when you choose a task list for a workflow. However, no matter how many workflow history lists you create, none of them will be directly accessible from within the site’s user interface.
We believe it is usually a best practice to create new workflow history lists for each workflow that is created by your end-users. There are several reasons to create separate workflow history and task lists. First, added workflow security allows you to lock down permissions on a workflow task list and/or a workflow history list (for instance, where users with the member role can still access documents, but won’t be able to access workflow details). A second reason is to keep workflow lists properly classified. Workflow task list categorization is especially relevant where a site includes several workflows and end-users are connecting the workflow task list to their Microsoft Office Outlook client. If all workflow tasks are routed to a single workflow task list, then every task will be synced to the Office Outlook client, even those tasks not relevant to the current user. Rather than routing all workflow tasks into a single task list, selecting disparate task lists for each workflow is a best practice when users sync those lists to their Outlook client.
A common workflow task list is a best practice when the workflow is invoked programmatically and the workflow tasks themselves are not reviewed frequently by your users or site administrators.
Note
Workflow history lists are not directly visible in a site’s View All Site Content page (or via the user interface). Workflow history lists also are not visible when using WebDav (My Network Places). This can be especially troublesome when you’ve created multiple workflow history lists to cater to different types of workflows within a document library and want to view or access those lists directly. A non-programmatic way to see all workflow lists within a site is to open the site in SharePoint Designer 2007.
There are implications in moving workflow history, such as when you move a document currently associated with a workflow in one document library to another document library. You need to be aware of this and consider it as part of your up-front workflow design and deployment.
If you move a document to another document library within the same site or to another site, workflow history associated with that document will not be moved and will become disconnected from the document. The document’s workflow history (defined when the workflow is created) will remain in the designated workflow history list in the site where the workflow was created. Why? The ID referenced in the workflow list is the list ID rather than the GUID. The association is valid only for the original document library in the site where the workflow is created, not another document library in the same site or in another site. Assigning out-of-the-box workflows to content types as opposed to a specific document library will help in terms of portability, that is, accessing workflows throughout an entire site collection as opposed to a workflow created within a document library (limited scope). However, you will still face the same issues when moving workflow documents. Saving a document library as a template, with or without the inclusion of content, will move the out-of-the-box workflows currently configured within that document library, including content types that are configured with a workflow. However, workflows currently in progress or workflow history will not be included as part of the template.
Another consideration in working with workflows and workflow history is that workflow history association is removed from documents after 60 days; that is, the workflow history list is still there but not easily accessible via the user interface, and the link to the original document is removed. So, if you are considering workflow strategies and maintaining workflow history as part of your workflow deployment, then consider the information in the following sidebar as a workaround, and implement it as part of your up-front workflow deployment strategy.