The SharePoint 2010 releases continue to build and improve the workflow functionality introduced in previous versions. Workflow development and implementation have become major forces in the business world, both in terms of streamlining office functions as well as cutting costs. Organizations that have adopted the SharePoint technology are slowly transitioning from manual unstructured processes to carefully structured, monitored functions. Knowing this inevitable transition is looming should be reason enough to get you interested in workflows and the benefits gained by this transition. The implementation of correctly designed workflows can give an organization many significant advantages. For one, they can give an organization the opportunity to restructure and reorganize common business processes. Workflows can modernize and automate these same business processes. Additionally, workflows create a chain of custody and an audit trail of all of the activities involved in the process. The purpose of this chapter is to make you aware of the significance of workflows and where they could be implemented in your organization.
This chapter examines the concept of workflows, how SharePoint 2010 enables workflow development, and deployment and security considerations. You will learn basic workflow concepts and be introduced to all of the workflow tools and features available to you as a SharePoint end-user, and how to use these tools to create basic and advanced workflows. Topics covered include:
- Workflow basics
- Creating workflows
- Managing workflows
- Workflow types
- Workflow authoring tools
- Workflow visualization
Before we get any further, it is important to understand what a workflow is and how it can impact a business. A workflow can be loosely defined as a sequence of connected steps performed by a person, a group of persons, an organization of staff, or one or more simple or complex mechanisms. It is used to describe the operations, procedural steps, organizations or people involved, and required input and output information, all included as part of a structured or unstructured business process.
We can better illustrate the concept of a workflow with an example of a common approval-type business process. Company Alpha has the following process for requisition requests.
This is illustrated as follows: A requisition form is filled out by an employee, which includes a description of the requested item, costs, details, and so on. This requisition form must then be approved by the head of the department that the employee belongs to. Once it is approved by the required department head, it must be approved by the organization's purchase manager.
This rather simple example can be broken down into the following workflow components.
The employee that submits a requisition form, the department head that approves or rejects the request, and the purchase manager that approves or rejects the request are all known participants in this business process. These participants form a chain of custody for the business process as data flows sequentially from one participant to the next.
The input data is the requisition form that is being filled out by the requesting employee. This form will contain the initial data (such as a description of the desired items, details, costs, required dates, and so on ) that will be used in the tasks by the department head and the purchase manager.
In this case, there are two decision-making tasks associated with this workflow. The department head will have to decide whether to approve or reject the request. If rejected, the initiator will need to be notified and the workflow will terminate. If approved, the workflow will move to the next workflow step and the purchase manager will have to decide whether to approve or reject the requisition request.
In this example, the output data consists of notification of the requisition request's approval or rejection. Once the workflow reaches one of its four conclusions, the employee that initially submitted the request will need to be notified as to whether or not his request was approved or rejected, as well as perhaps a reason if it is rejected.
The components described previously are typical of almost all workflows, so when you are designing and deploying a workflow it is important that these are understood.
Tip
We estimate that 80 percent of a workflow deployment initiative is requirement gathering, rather than the point-click experience with the SharePoint interface.
SharePoint workflows are based on the Windows Workflow Foundation (WF) and part of the .NET 3.5 Framework that essentially consists of three components:
- Runtime engine: This provides the workflow execution environment, transactions, persistence, state management, and tracking capabilities.
- Hosting application: This provides the execution context for the runtime engine as well as any application-specific services that may be required to support the workflows, such as the SharePoint library or list.
- Activities: These are based on the WF framework's base activity library; they are the building blocks of the workflow.
This was a brief architectural understanding description of the foundation of SharePoint workflows. These three components are always working behind the scenes when you are creating and executing workflows.
A more in-depth examination is outside the scope of this book and can be found in a variety of published materials dealing with SharePoint 2010 development.
There are basically two kinds of workflows: sequential and state-machine.
These perform their actions in sequence, one after another from start to finish. Although they might seem rigid, these workflows can be made more flexible by adding, looping, branching, and other flow control mechanisms. Additionally, branching decisions can be made based on values that are passed in from outside sources, or based on actions made by end users. Processes that can be easily automated make good candidates for state machine workflows, because steps can be easily added. A few examples may include an employee performance review, a company travel system, and the requisition request form described in the beginning of this section.
These can be broken down into states and state transitions. They perform different actions based on specific events, which can be simple or complex. Instead of defining a sequential path from start to finish, the workflow goes through many potential states before reaching completion. For example, the workflow can transition from state A to state B, or skip state B and transition to state C based on the event received in the workflow. Good candidates for state-machine workflows include help desk systems, employee onboarding systems, purchasing systems, and so on.
Now that you have had a basic introduction into workflows and the different types of workflows, we will see how they apply to the different versions and editions of SharePoint 2010.