1. Understanding Human Workflows
Human workflows in
SharePoint 2010 are used for defining how people work and collaborate.
These workflows apply business logic to the SharePoint content and
execute business rules either on demand or automatically. For example,
document approval and feedback, collaborative reviews and discussions,
gathering signatures on documents, and translation of content into
specific languages are some of the human workflows available in
SharePoint 2010.
SharePoint 2010 acts as a
platform to host workflows. This enables an organization to implement
various custom workflows that cater to their business requirements.
These workflows can tie together various business processes that span
all of an organization’s departments on a single collaboration platform.
For example, assume an
organization has a defined process for recruitment officers of the
Human Resources (HR) department to submit a list of resumes along with
an initial assessment of each candidate’s competencies to each business
unit’s interview panel. The interview panel then conducts the interviews
and submits their assessments on technical competency with a review
status of selected or rejected.
If the candidate is selected, the business unit’s hiring manager must
conduct a second interview and inform the HR department about whether
the candidate will be recruited. The HR department then negotiates the
compensation and other related details with the candidate and completes
the recruitment process. As you can see, this is a
multidepartment/multistage, people-intensive business process.
SharePoint 2010 can be used for implementing this business process
through custom workflows with the help of either InfoPath forms or
ASP.Net, which will act as the interface to capture the data involved in
the process.
2. Understanding System Workflows
System workflows in
SharePoint 2010 are used primarily for automating processes that
interact with the content and data stored in SharePoint. These
workflows, when triggered by users, will move data in and out of
SharePoint. For instance, your organization might want to create
workflows that move documents from collaboration sites to the record
center when the document’s expiration date is reached. The end users are
not involved in the process of moving the document or even in
triggering the workflow. The workflow in this case is based on the state
of the document. System workflows can be created to interact with
external systems and collect data, which can be imported into SharePoint
2010.
Another instance in which you
can use system workflows is to send periodic reports on data stored in
SharePoint, such as consolidated expense reports on a monthly basis, or
the number of help desk tickets closed by service level on a weekly
basis. For all these scenarios, workflows can be created and activated
on the sites needed. The end user can associate these workflows to a
site or library as needed and define the schedule (such as monthly or
weekly) or state (document is published, expired, etc.) on which the
workflows should run. SharePoint 2010 Web Analytics and Usage reports
are system workflows that send periodic site usage and analytical
reports to selected participants.
Note:
Timer
jobs can be used for some of these activities, but timer jobs can be
activated and managed only by SharePoint 2010 farm administrators. End
users cannot control the execution of the timer jobs. The choice between
using a timer job and using system workflows should be based on end
user’s control over the process in terms of schedule and other possible
factors. If the end users do not need to control the process, then
choose timer jobs; otherwise, choose system workflows.
3. Workflows in SharePoint 2010
SharePoint 2010 is a rich
workflow platform that provides a wide range of predefined workflows and
a rich set of workflow modeling and development tools. In the following
sections, you explore the concepts of SharePoint workflows,
improvements provided in SharePoint 2010, and the set of workflows
available by default in SharePoint 2010.
Any SharePoint workflow has
defined stages for information processing, along with unique forms for
the collection of data. Typically, a workflow has the following stages:
association, initiation, and a set of tasks. At each stage, a form is
used to collect information from the end users. In addition, after a
workflow is created, it can be modified—a fourth stage.
3.1. Workflow Stages and Forms
The business logic of a workflow
is implemented through a set of tasks and their associated business
rules. In addition to these tasks, each workflow has an association,
initiation, and modification stage.
Association
When an administrator associates a workflow template with a document
library, list, or site, he or she might be able to set options that will
apply to every workflow instance created using this association. An
ASP.Net or InfoPath form that is associated with the workflow is used to
collect the needed association data from the administrator.
Initiation
The initiator of a workflow might be allowed to specify options when
the workflow instance is started. For example, in the approval workflow
scenario, the initiator is allowed to specify different stages in
approval and the list of workflow participants in each stage, as well as
define how much time each participant has to complete his or her task.
An initiation form is associated with the workflow for the initiator to
specify the initiation data. The initiation data is available for
workflow developers and modelers to use during the execution business
logic.
Task Forms
A workflow instance interacts with the participants through defined
workflow tasks. The running workflow instance must display a form to the
participants for them to complete their task. The task form collects
the data from the participant. For example, in the approval workflow
scenario, data collected might include whether the document is approved
or rejected, along with comments. Depending on the complexity of the
workflow, a number of task forms can signify different stages of the workflow.
Modification
The creator of a workflow can allow it to be modified while it is
running. For example, a workflow might allow the addition of new
participants while running, or it might allow an extension of the due
date for completing tasks. If this option is used, the workflow must
display a form that captures a participant’s changes.
3.2. SharePoint 2010 Workflow Types by Packaging and Deployment
Workflows in SharePoint 2010 can be classified as declarative or compiled, based on how they are created, packaged, and deployed.
Declarative workflows You create declarative workflows using Microsoft SharePoint Designer 2010 and deploy them using Extensible
Object Markup Language (XOML) files. Declarative workflows are created
using rules, actions, and a set of parameters without writing any code.
These rules, actions, and parameters are captured in the XOML file and are compiled at run time from the content database of the Web application.
Compiled workflows
Compiled workflows are also created with a set of rules and actions in
the form of steps and parameters, but they are compiled into an assembly
and deployed into the Global Assembly Cache (GAC).
Developers create compiled workflows in Microsoft Visual Studio 2010,
and these workflows are packaged into features and solution packages
(WSP). Compiled workflows allow the developer to write code to perform
actions that are not available in Visual Studio 2010 workflow project
templates.
3.3. SharePoint 2010 Workflow Types by Associations
SharePoint Server 2007 allowed
workflows to be associated with items on a list or library, whereas
SharePoint 2010 adds the capability to associate a workflow with a site
as well. With this improvement, SharePoint 2010 has three types of
workflows by association.
List workflows
This type of workflow is associated with a list or library and is
initiated using an item or document in that list. An example would be
the Translation Management workflow, which is associated with the
translation library by default.
Content type workflows
Content type workflows are associated with content types and are
available to all lists or libraries within which those content types are
used. Workflows can also be associated with a list content type. An
example would be the Collect Feedback and Content Approval workflows,
which are associated with the Document content type.
Site workflows
Site level workflows are new in SharePoint 2010. Site workflows are
associated with a site and are independent of any item or document. In
SharePoint 2010, Web Analytics workflows are site workflows and are used
to send usage analysis reports to participants. Custom site workflows
can be created using Visual Studio 2010 and SharePoint Designer 2010.
3.4. SharePoint 2010 Workflow Improvements
SharePoint 2010 provides many improvements to the workflow platform
when compared with prior versions of the product. You have already been
introduced to site workflows, which were not provided in SharePoint
Server 2007. Improvements have been made to the authoring tools as well,
making SharePoint 2010 a powerful workflow hosting platform. You will
learn more about specific improvements made to the workflow platform
within SharePoint 2010 in the following sections.
3.4.1. Workflow Modeling Tool Improvements
SharePoint 2010 workflows
can be created using Visual Studio 2010, SharePoint Designer 2010, and
Microsoft Visio 2010. Visual Studio 2010 has improved workflow project
templates and workflow activities. Visual Studio 2010 also allows the
developer to create and deploy SharePoint solution package (WSPs),
making it easier to develop, deploy, and debug workflows.
SharePoint Designer 2010
provides a streamlined user interface for developing workflows.
SharePoint Designer 2010 also allows you to edit out-of-the-box
workflows to meet your specific business requirements. In SharePoint
Designer 2007, you could use only ASP.Net for creating workflow forms,
whereas in SharePoint Designer 2010, you can create InfoPath-based
forms. Note that to use this functionality you must have InfoPath 2010
installed on the same computer where SharePoint Designer is installed.
SharePoint Designer 2010 includes a task process designer that lets you
define different outcomes for the activities in the workflow.
Also, business processes
designed in Visio 2010 can be imported into SharePoint Designer 2010 for
deployment. Visio 2010 supports Business Process Modeling Notations
(BPMN), which makes it easy for end users to create complex business
processes that can be deployed as workflows in SharePoint 2010 using
SharePoint Designer 2010.
3.4.2. Site Workflows
In prior versions of SharePoint, you could only associate a workflow with a list item for execution.
In SharePoint 2010, workflows can be associated with a site, which
gives information workers the flexibility to create workflows that are
not dependent on changes to list items. Site workflows have to be
started from the Site Actions menu of a site. Site workflows should be
started manually or through the SharePoint API.
3.4.3. Reusable Declarative Workflows
Reusable declarative
workflows are created using SharePoint Designer 2010. These workflows
are created once and can be associated with multiple lists in the same
site as well as lists in other site collections.
3.4.4. Impersonation in Declarative Workflows
SharePoint 2010 allows
information workers to create portions of a workflow that can
impersonate the workflow author’s permissions instead of those of the
logged-on user. This allows the workflow to perform actions that cannot
be executed with the permissions of the user who is logged on.
3.4.5. Timer-Based Execution
In prior versions of
SharePoint, the entire workflow was executed on the Web front-end server
by the Internet Information Services (IIS) worker process even if
workflow activities did not involve any user interactions. In SharePoint
2010, the workflow execution is performed by the Timer service if
The workflow activity does not involve any user inputs.
The workflow is continued from a delay timer.
The workflow is triggered by an external event.
3.4.6. Workflow List Events
SharePoint 2010 provides an
option for developers to perform the initiation and completion of
workflows through events. The four SharePoint workflow list level events
are Starting, Started, Completed and Postponed. These events can be
handled like other list events, using an event receiver and project
templates that are available in Visual Studio 2010. These events are
available only for the workflows associated with lists; they will not
work for site workflows.
3.4.7. Pluggable Workflow Service
In prior versions, workflows
enabled users to participate in business processes that were automated
within SharePoint, but it was difficult to tie the workflow execution
back to external systems. This problem has been addressed in SharePoint
2010 with the help of a Pluggable Workflow Service that provides
interfaces through which SharePoint workflows can interact with external
systems and vice versa.
The Pluggable
Workflow Service interface is exposed through the CallExternalMethod and
HandleExternalEvent methods. CallExternalMethod allows a workflow to
interact with external systems using asynchronous messages.
HandleExternalEvent allows the external systems to trigger an event on
the workflows
and in turn allows the workflow to respond to the event from the
external system. The Pluggable Workflow Service is adopted into the
SharePoint workflow platform from Window Workflow Foundation, which is provided as part of the .NET 3.5 Framework.
3.4.8. Improved Compliance Capabilities
SharePoint 2010 allows
farm administrators to configure Web applications to enable or disable
user-created workflows. This capability provides a control to the farm
administrators to isolate Web applications where such workflows are not
allowed; it also prevents end users from creating such workflows. For
example, you can prevent end users from creating workflows on record
center Web applications.
Farm administrators
can also control how to handle task notifications to workflow
participants who do not have access to the content on which the workflow
is executing. This setting allows different configurations for internal
and external users. This configuration option (to give workflow access
to those who do not have access to the content) is available at the Web
application as well.
3.5. Predefined Workflows of SharePoint 2010
In the following sections, you
will see the list of workflows available within SharePoint 2010 and
review when to use them. SharePoint 2010 includes the following
predefined workflow templates, which address common business scenarios.
Collect Feedback
Approval
Disposition Approval
Collect Signatures
Three-state
Translation Management
You can customize all of these workflows based on your specific requirements. For example, you can modify the Approval
workflow so that it provides a multistage approval process with a
different kind of task allocation for each stage. Moreover, SharePoint
2010 allows you to copy these predefined workflows and customize them
using SharePoint Designer 2010.
3.5.1. Collect Feedback Workflow
The Collect Feedback workflow
routes a document or item to a group of people for feedback. Reviewers
provide the feedback, which is then compiled and sent to the workflow
initiator. By default, the Collect Feedback workflow is associated with
the Document content type, and therefore it is automatically available
in document libraries. You can use this workflow to request feedback on
the documents from a group of reviewers and then use the information
gleaned from the workflow to update the document with the suggested
changes. This workflow is highly effective when collaboratively
developing document content.
3.5.2. Approval Workflow
The Approval workflow
routes a document or item to a group of people for approval. By default,
the Approval workflow is associated with the Document content type, and
therefore it is automatically available in document libraries. A
version of the Approval workflow is also associated by default with the
Pages library of a publishing site and can be used to manage the
approval process for the publication of Web content.
The Approval workflow
provides a staged approval model (that is, the first set of approvers
can undergo the review and approval process, then the next set of
approvers, and so on). Each stage or approval set can also have its own
behavior. For example, members of the first group of approvers can do
their review in serial approval order (one after the other), while
members of the second group can do their review in parallel (reviewers
can provide feedback in any order), and so on.
An Approval workflow is
useful in many common business approval scenarios, including expense
report approval, interview candidate selection processes, and contract
approval.
3.5.3. Disposition Approval Workflow
The Disposition
Approval workflow manages document expiration by letting participants
decide whether to keep or delete expired-documents. The Disposition
Approval workflow is used in record management scenarios and hence
available only in a Records Center site. Disposition approval workflows
can be associated with content types by configuring Information
Management Policy settings. You can use the Disposition Approval
workflow in your record center sites for records that need special
attention at the time of expiration.
3.5.4. Collect Signatures Workflow
The Collect Signatures
workflow routes a document that was created within an Office application
to a group of people to collect their digital signatures. This workflow
must be started within Microsoft Office 2007 or 2010 applications such
as Microsoft Word. Participants must complete their signature tasks by
adding their digital signatures to the documents in the relevant client
program. By default, the Collect Signatures workflow is associated with
the Document content type and therefore is automatically available in
document libraries. However, the Collect Signatures workflow appears only if the document stored contains one or more Microsoft Office signature lines.
3.5.5. Three-state Workflow
The Three-state workflow is
designed to track the status of a list item through three states
(phases). It can be used to manage business processes that require
organizations to track a high volume of issues or items, such as
customer support issues, sales leads, or project tasks.
The Three-state workflow is so
named because it tracks the status of an issue or item through three
different states, and through the two transitions between the states.
For example, when a workflow is initiated on an issue in an Issues list,
SharePoint 2010 creates a task for the assigned user. When the user
completes the task, the workflow changes from its initial state (Active)
to its middle state (Resolved) and creates a new task for the assigned
user. When the user completes that task, the workflow changes from its
middle state (Resolved) to its final state (Closed) and creates a final
task for the user to whom the workflow is assigned at that time. Note
that this workflow is only supported on lists, not document libraries.
Note:
The Three-state workflow is the only workflow available in SharePoint Foundation 2010.
3.5.6. Translation Management
The Translation
Management workflow manages manual document translation by creating
copies of the document to be translated and by assigning translation
tasks to translators. This workflow is available only for Translation
Management libraries and is used with site variations.
