Workflows represent a series of actions and decisions within a larger process that are committed in a particular order. The more ordered a process is, the easier it is to record that process electronically in a workflow. An example is how an expense claim is managed internally between an employee and the company. An employee submits an online expense claim, which is either approved or disapproved by her manager. This determines the next step in the workflow, such as the approved expense claim being routed to accounts so that employee reimbursement can be organized.
Workflows automate otherwise manual and repetitive business processes and add some smarts to routing processes within workflows, such as e-mailing one or more end-users during the workflow process, assigning tasks, and setting conditions that need to be met before a workflow can progress. For example, a basic workflow can be envisioned by using a flowchart like the one shown in Figure 10-1. Point A is the input stage or beginning, such as an online expense claim. This triggers a workflow. Point B is the decision point, which determines the next step or stage of the workflow. For example, Yes approves an online expense claim, while No disapproves the same claim and sends an e-mail to the submitter requesting additional information or adjustments. The workflow will end once all of the conditions within the workflow are met and an outcome is achieved.
Microsoft Office SharePoint Server 2007 includes a wealth of built-in workflow features, including workflows specific to documents, approvals, content expiration, user feedback, and publishing. Workflows can be associated with documents and items, document libraries and lists, as well as specific types of content, referred to as content types. Microsoft Office SharePoint Designer 2007 includes a workflow designer that can be used to extend the out-of-the-box workflows. In addition, enhanced workflow features can be integrated throughout SharePoint sites and site collections using Microsoft Visual Studio 2005 in conjunction with Windows Workflow Foundation, Microsoft Office InfoPath, and the SharePoint Object Model.
In this chapter, we’ll focus on the out-of-the-box workflows and custom workflows created using Office SharePoint Designer 2007, and we’ll discuss best practices for creating workflows throughout SharePoint deployments using these technologies.
An automated workflow process can potentially replace existing manual, or labor-intensive, business processes and boost productivity throughout an organization. But you must first identify where and how you can adapt workflows to best meet business requirements. For example, do you have any existing processes that demand a great deal of user-generated e-mail, or are you still using a paper-based solution that has the potential to be replaced by an online workflow?
Two examples of how companies have utilized automated workflows include the following:
A document review and approval process; for example, project technical and functional specifications that need to be reviewed and approved by multiple team members
A company travel system in which employees must submit a travel request to their manager and have that request approved before it can be sent to the travel agency for airline and hotel bookings
Workflows within SharePoint can be as simple as triggering an e-mail when a document is uploaded to a document library or as complex as workflows that interact with back-end Line-of-Business (LOB) systems, such as SAP.
Before creating workflows, you need to assess potential workflow candidates by reviewing your existing business processes. Best practice is to hire a good business analyst to help you assess your existing processes and consider issues such as employee productivity drain. Even 5 to 10 minutes per day, every day, for each employee can have a significant impact on overall company productivity. Workflows can also add control, consistency, and structure to business processes. But remember, embarking on an automated workflow project where the underlying processes haven’t been fully identified and assessed can lead to project failure, budget blowout, and an unprofitable end solution that helps no one. For instance, if discussions focus predominantly around the workflow technology solution rather than the actual process, then the project is at risk of failing to identify correct candidates for automated workflow and doomed to failure. Best practice is to ensure that you have correctly documented the actual workflow before trying to replicate it electronically.
Once you’ve identified existing and/or new candidates for automated workflow processes, you’re ready to choose exactly what workflow technology you’ll use. In other words, you should adapt the technology to the business requirements rather than the other way around. That is, fit the business requirements to the technology. One size doesn’t fit all!
A commonly used workflow within SharePoint sites is the document approval workflow, which is available as an out-of-the-box workflow. SharePoint Designer 2007 adds the ability to create code-free custom workflows that extend out-of-the-box workflows. For example, you can use SharePoint Designer 2007 to add a multiple-step workflow to progress a document through several approval stages and move the document into another document library based on a certain condition. A more complex workflow, such as one involving integration with a LOB system like SAP, will involve using Visual Studio. Table 10-1 details the key differences between workflows created using the out-of-the-box workflows, custom workflows created in SharePoint Designer 2007, and workflows created using Visual Studio.
Table 10-1. Comparison Between Workflow Tools
Workflow tool | Functionality | Complexity |
|---|---|---|
Default out-of-the-box workflows | Application Task and Issue Tracking, Routing and Approval, Review Approval, Signature Collection | Ad hoc |
SharePoint Designer 2007 workflows | Custom Form Actions, Document Processes, Weekly Status Report, Service Requests, Asset Tracking | Ad hoc/structured |
Visual Studio 2005 and Workflow SDK | Line of Business Integration, Purchase Order Processing, Product Lifecycle Management | Structured/requires coding |
The degree of complexity for each method is also listed in Table 10-1. This is something else you will need to consider as part of your up-front workflow design and strategy. For example, will you need to hire additional resources to build custom workflows, or will you be able to address your workflow requirements with the out-of-the-box workflows?