Workflows overview (SharePoint Foundation 2010)
Applies to: SharePoint Foundation 2010
The workflow feature in Microsoft SharePoint Foundation 2010 enables solution architects, designers, and administrators to improve business processes. Fundamentally, a workflow consists of two things: the forms that a workflow uses to interact with its users and the logic that defines the workflow’s behavior. Understanding how workflows are created requires knowledge about both.
In this article:
Workflow overview
Benefits of using workflows
Predefined workflows
Sample workflow scenario
Workflow types: Declarative and code-centric
Workflow templates
Workflow associations
Workflow overview
Workflows in SharePoint Foundation 2010 enable enterprises to reduce the amount of unnecessary interactions between people as they perform business processes. For example, to reach a decision, groups typically follow a series of steps. The steps can be a formal, standard operating procedure, or an informal implicitly understood way to operate. Collectively, the steps represent a business process. The number of human interactions that occur in business processes can inhibit speed and the quality of decisions. Software that simplifies and manages this "human workflow" enables the automation of interactions among groups who participate in the process. This automation results in more speed, overall effectiveness of the interactions, and often a reduction in errors.
You can model business processes by using flow charts, such as those created using Microsoft Visio 2010 and can represent business processes by using workflow terminology. You can automate business processes, such as document approval, by associating a workflow with data in SharePoint Foundation 2010. For example, you can create a workflow to route a document for review, track an issue through its various stages of resolution, or guide a contract through an approval process.
One problem that many IT departments face when implementing business processes that require participation of information workers is that those processes do not integrate with the way people actually work. For a business process to be effective, it must be integrated with the familiar, everyday tools and applications used in the workplace so that it becomes part of the daily routine of information workers. In the electronic workplace, this includes integration with e-mail, calendars, task lists, and collaboration Web sites.
Benefits of using workflows
The primary benefits of using workflows are to facilitate business processes and improve collaboration.
Business processes that enterprises use depend on the flow of information or documents. These business processes require the active participation of information workers to complete tasks that contribute to their workgroup's decisions or deliverables. In SharePoint Foundation 2010, these types of business processes are implemented and managed by using workflows.
Examples of business processes that could be facilitated by workflows include:
Contract approval Guiding a proposed contract among members of an organization who must approve or reject it.
Expense reporting Managing the submission of an expense report and associated receipts, reviewing the report, approving it, and reimbursing the submitter.
Technical support Guiding the progress of a technical support incident as it is opened by a customer, investigated by a support engineer, routed to technical experts, resolved, and added to a knowledge base.
Interviewing Managing the process of interviewing a job candidate. This includes scheduling and tracking interview appointments, collecting interview feedback as it accumulates, making that feedback available to subsequent interviewers, and facilitating the hire/no-hire decision.
Automating business processes
Businesses depend on business processes. Although those processes often involve software, the most important processes in many organizations depend on people. Workflows can automate interactions among the people who participate in a process to improve how that process functions, increase its efficiency, and lower its error rate.
Many processes can benefit from automated support for human interactions. Examples include the following:
Approval A common aspect of human-oriented business processes is the requirement to get approval from multiple participants. What is being approved can vary widely, ranging from a Microsoft Word document that contains next year’s marketing plan to an expense report from a trip to a conference. In every case, some number of people must review the information, perhaps appending comments, and then indicate approval or rejection.
Coordinating group efforts Whether it is preparing a response to a request for proposal (RFP), managing the translation of a document into one or more languages, or something else, many processes require people to work together in an organized way. By defining the steps of the process through an automated workflow, the group’s work can be made more efficient and the process itself more predictable.
Issue tracking Many business processes generate a list of outstanding issues. An automated workflow can be used to maintain that list, assign issues to the people who can resolve them, and track the status of that resolution.
To support these kinds of automated business processes, SharePoint Foundation 2010 can run workflow applications. Based on Windows Workflow Foundation 3.5, these applications interact with people through a Web browser. For more information about Windows Workflow Foundation 3.5, see Windows Workflow Foundation (https://go.microsoft.com/fwlink/p/?LinkId=127778).
Workflows improve collaboration
Workflows help people collaborate on documents and manage project tasks by implementing business processes on documents and items on a SharePoint site or site collection. Workflows help organizations follow consistent business process practices. Workflows increase organizational efficiency and productivity through management of the tasks and steps involved in those business processes. Workflows speed up decision making by helping to ensure that the appropriate information is made available to the appropriate people at the time that they need it. Workflows also help ensure that individual workflow tasks are completed by the appropriate people and in the appropriate sequence. This enables the people who perform these tasks to concentrate on performing the work instead of on the work processes.
For example, on a SharePoint Foundation 2010 site, you can create a workflow to be used with a document library to route a document to a group of people for approval. When the author starts this workflow, the workflow creates document approval tasks, assigns these tasks to the workflow participants, and then sends e-mail alerts to the participants.
When the workflow is in progress, the workflow owner or the workflow participants can check progress on the Workflow Status page. When the workflow participants complete their workflow tasks, the workflow ends, and the workflow owner is automatically notified that the workflow has finished.
Predefined workflows
For sites and site collections created in Microsoft SharePoint Foundation 2010, a predefined Three-state workflow is included by default, and is the only predefined workflow available in SharePoint Foundation 2010. The Three-state workflow can be used to manage business processes that require organizations to track a high volume of issues or list 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 two transitions between the states. For example, when a Three-state workflow is initiated on an issue in an Issues list, SharePoint Foundation 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 task for the assigned user. When the user completes the task, the workflow changes from its middle state (Resolved) to its final state (Closed), and creates another task for the user the workflow is assigned to at that time. Note that when you associate the Three-state workflow with a list, you can choose to specify different state names, other than Active, Resolved, and Closed. Note that the Three-state workflow is not supported for use with libraries.
You can also make a copy of the predefined workflow to use as a starting point when creating a custom workflow.
Sample workflow scenario
Imagine that you work for Adventure Works, a sports store franchise that sells bicycles worldwide. This company has sales representatives that visit different countries to help new franchisees open new sports stores.
The scenario described in this section is one where an expense report is submitted for approval. If the expense report is for less than $5,000.00, a manager is required to approve, disapprove, or forward it. If the expense report is equal to, or more than, $5,000.00, a manager must review the expense report, comment on it, and then if the manager recommends approval, it is forwarded to a vice-president, who must approve or disapprove it.
In this scenario, the expense report form is an ASPX form displayed to the user on a SharePoint Web page. The workflow is a sequential type of workflow project created in Microsoft SharePoint Designer 2010, and is composed of both automated tasks and tasks that require human action. The workflow is running on SharePoint Foundation 2010.
The sales representative — the first workflow participant — browses to an intranet self-service portal and selects the Expense Report form. A data entry page opens. The sales representative first fills out a simple expense report form that contains entries for the person’s name, the expense purpose, the expense total, and the name and e-mail address of the person’s direct manager. The sales representative then clicks Submit to submit the form.
Upon submission of the form, the data is saved centrally, the workflow is initiated, and the review task is assigned to the approver (in this case, the sales representative’s manager).
The workflow notifies the sales representative’s manager. The notification is an e-mail message that contains instructions for completing the task and provides a link to a Web site that displays the Expense Report form.
The manager, the second workflow participant, goes to the Web site and reviews the expense report. The workflow task item provides three actions that the manager can perform: Approve, Disapprove or Forward.
If the expense report is less than $5,000.00, the manager sees options to Approve or Disapprove the expense report.
If the expense report is more than $5,000.00, the manager sees options to Forward the expense report to a company vice president, or to Disapprove the expense report at the manager’s level.
The manager takes action to approve, disapprove, or forward the expense report, and the workflow continues:
If the expenses are approved by the manager, the task completion sends a message to the workflow indicating that the task is completed, the workflow notifies the sales representative through an e-mail message, and then the workflow adds the expense data to the line-of-business (LOB) accounting system.
If the expenses are not approved by the manger, he types an explanation for his decision. The task completion sends a message to the workflow indicating that the task is completed, and then the workflow notifies the sales representative through an e-mail message.
If the manager selects the option to forward the expense report to a company vice president, the manager makes relevant comments in the form and then clicks Forward. The workflow then notifies the vice president through an e-mail message that contains instructions for completing the task and provides a link to a Web site that displays the Expense Report form.
The vice president — the third workflow participant — is given the option to Approve or Disapprove the expense report. When the vice president acts to approve or disapprove the expense report, the workflow continues.
If the vice president approves the expenses, the expense data is added to the accounting system, the workflow notifies the sales representative and manager through e-mail, and then the workflow notifies SharePoint that the task is completed.
If the vice president does not approve the expenses, the vice president types an explanation for the decision into the form. The workflow notifies the sales representative and manager through e-mail, and then the workflow notifies SharePoint that the task is completed.
As you can imagine, there are many ways to expand the functionality of this workflow within the context of this scenario. For example, you can configure the workflow so that if the vice president disapproves the expense report, the report is returned to the sales representative’s manager. The manager can further justify the expense and resubmit it for approval to the vice president, can pass along the disapproval to the sales representative, or take some other action.
In this sample expense report scenario, the business rules are always the same. This workflow solution defines the manager and vice president approvers, defines the business logic for the routing of the workflow, and predefines the content of the notifications. However, many real-world applications have complex business rules. Routing for approval can depend on many business variables. Notifications can also change, depending on other variables.
For example, imagine that in the same expense reporting solution, you have to route the expense report to as many as ten managers, depending on the expense purpose, the expense total, and the date of submission. Additionally, depending on the expense purpose, the content of the notifications sent by the workflow contain some small differences. This means that there can be multiple workflow solutions with different routing levels and notifications.
Microsoft SharePoint Foundation 2010 enables you to create and implement workflow solutions to meet the business needs of your organization. It does this by leveraging the workflow design and customization features of SharePoint Designer 2010 and Microsoft Visual Studio.
Workflow types: Declarative and compiled
An important distinction to understand about workflows is whether they are a declarative workflow, such as those created using Microsoft SharePoint Designer 2010 or a compiled workflow, such as those created using Visual Studio 2010. A declarative workflow is a workflow that is built from conditions and actions that are assembled into rules and steps, and that sets the parameters for the workflow without writing any code.
A compiled workflow, like declarative workflows, can also be built from conditions and actions without the workflow author actually writing code but also enable the workflow author to add custom code to the workflow. Regardless of whether a workflow author adds custom code to a code-centric workflow, the most important distinction to understand is the difference in the way that declarative and compiled workflows are run on the server. A compiled workflow is stored on a server running SharePoint Foundation 2010 as a precompiled dll file whereas a declarative workflow is deployed on a server running SharePoint Foundation 2010 as an Extensible Object Markup Language (XOML) file and compiled in the content database each time an instance of the workflow is started.
For more information about the Microsoft supported tools for authoring workflows, see Choose a workflow authoring tool (SharePoint Foundation 2010).
Workflow templates
When creating a custom workflow using SharePoint Designer 2010, you can choose to create a workflow that will only be used with a specific list, library, content type, or site. Alternatively, you can choose to create a reusable workflow template, which can be associated with multiple lists, libraries, content types, or sites.
Note
SharePoint Designer 2010 does not support creating reusable workflows for sites. Instead, you can use Visual Studio 2010 to create them.
When authoring a workflow, you can also choose to make it global, which means that once it is activated on a site it will be active for all the sub-sites below that site as well. However, you cannot use SharePoint Designer 2010 to create a global workflow and then save the workflow as a WSP file.
Workflow associations
SharePoint Foundation 2010 takes advantage of the Workflow Foundation runtime. One or more workflow templates, each containing the code that defines a particular workflow, can be installed on a server. Once this is done, an association can be created between a specific template and a document library, list, content type, or site. This template can then be loaded and executed by the SharePoint Foundation 2010-hosted Workflow Foundation runtime, creating a workflow instance.
Like all Workflow Foundation workflows, those based on SharePoint Foundation 2010 rely on Workflow Foundation runtime services. The Workflow Foundation standard persistence service allows the state of a persisted workflow to be linked with the document or item, and allows for long-running business processes that can span days, months, or years.
SharePoint workflows can be associated with lists, libraries, and content types. Reusable workflows created using Visual Studio 2010 can also be associated with sites. The following table describes the minimum permissions required to associate a workflow.
| Associate workflow with | Minimum permissions required |
|---|---|
List or library |
Full Control permission level on the list or library |
List or library content type |
Member of the Site Owners group on the SharePoint site |
Site content type |
Member of the Site Owners group on the SharePoint site |
Site |
Member of the Site Owners group on the SharePoint site |
For more information about workflow associations, see Add a workflow association (SharePoint Foundation 2010).