Building Effective Workflows Using SharePoint Server 2010

Article
10/20/2016

Summary: Learn about tools and approaches for creating Microsoft SharePoint 2010 workflow solutions by using SharePoint Server 2010 and SharePoint Designer 2010, and find out which tools and approaches are best for different scenarios.

Provided by: Microsoft Corporation

Contents

Introduction to Building Workflows Using SharePoint Server 2010
SharePoint 2010 Workflow Structure, Security Rules, and Automation Features
Using Built-in Workflows in SharePoint 2010 to Streamline a Business Process
Using SharePoint Designer 2010 to Extend and Manage Workflows
Extending SharePoint Designer Workflows Using Business Connectivity Services (BCS)
Extending SharePoint Designer Workflows Using Custom Activities
Building Visual Studio Workflows
Workflow Templates and Other Built-in Functionality in SharePoint Server and SharePoint Designer 2010
Conclusion
Additional Resources

Introduction to Building Workflows Using SharePoint Server 2010

As organizations try to "do more with less," they increasingly depend on the effective flow of information to make good decisions and improve worker efficiency. Simply put, information must reach the right people, at the right time, and in the right form so that the appropriate action can happen. As such, companies spend much time and effort defining and executing business processes to facilitate the proper flow of information.

Automating and Managing Human Workflow Using SharePoint 2010 Workflow Tools

Many unplanned and manual human workflows can be inefficient, time-consuming, and difficult. Fortunately, with the Microsoft SharePoint 2010 workflow tools, a worker can, without advanced development or other specialized skills, automate processes to improve productivity at both the individual and enterprise levels.

Business workflow experts, developers, and IT professionals alike consistently receive one important request from users: Provide technology solutions to help automate and manage business processes. The benefits of automation may seem obvious, but they should not be underestimated:

The less time people spend manually interacting with process, the more time they have for solving problems and adding value. People can quickly stagnate when process becomes slowed down at a particular point—when a task "sits on someone’s desk" for a long time (often repeated across several people), inefficiency is magnified. Automation can help keep process in motion.
Automation can help ensure that processes are consistent and repeatable across the organization, limiting the problems and costs associated with people and teams. You do not have to design different, ad hoc processes for similar problems.
With established and efficient automated processes in place, bringing new or transient employees on board is much easier and involves less risk.

Within a typical organization, business processes and the flow of information are largely manual—many workflows are about actions that people perform. For example, when an employee sends a document through email to a supervisor for comment or approval, a very simple human workflow is created. Human workflows can range from this simple, ad hoc example to a more complex, well-defined enterprise best practice. However, all human workflows share the characteristic that participants in the workflow are people who have varying roles and responsibilities.

Often, but not exclusively, these human workflows are document-centric. Therefore, an organization must structure the way people collaborate on a document, review and approve drafts, and control the process for version submission and disposition.

Additional examples of human workflows include:

Administrative functions, such as vacation approvals and special request expense forms.
Structured collaboration that uses the document management and collaboration components of SharePoint. Workflows promote better collaboration on documents like sales proposals and product specifications, which require timely input and approval from a variety of resources across different teams.

Workflow Features in SharePoint 2010

Yet, for all the benefits of automation, using software solutions to improve business processes can create another set of complications—whether purchased or built in-house, software systems can add substantial complexity. For example, these systems may demand such a high degree of expertise that only professional developers or other specialists can create solutions. However, these experts may not have sufficient experience to model processes in the way that they are actually used by other employees.

The workflow feature in Microsoft SharePoint Server 2010 helps bridge the gap between knowledge and tool set. Using Microsoft Office 2010 tools (including Microsoft Visio 2010 and SharePoint Designer 2010) together with SharePoint Server 2010, almost anyone can easily design workflows to model and automate a wide range of business processes, all without writing code. For developers and other specialists, SharePoint Server 2010 and its associated applications also provide powerful options and great flexibility for adding highly customized functionality when required.

Windows Workflow Foundation, the Microsoft engine for workflow development, provides a programming model, in-process workflow engine, and rehostable designer to implement long-running processes as workflows within Microsoft .NET Framework applications. First released in 2006, Windows Workflow Foundation is an extremely powerful tool for developers to build and execute application logic.

SharePoint Server 2010 hosts Windows Workflow Foundation and extends its power to workers who may not have the deep development skills that creating workflow solutions might demand. Likewise, the workflow feature in SharePoint Server 2010 can help automate business processes and ensure that they run consistently. With the deep functionality of Windows Workflow Foundation and related SharePoint features, solution architects, designers, and administrators alike can help quickly and easily improve business processes.

As with many technologies that help people create solutions, SharePoint workflow enables a variety of tools and approaches that all can achieve the same goals. This article discusses those various capabilities and examines why and how each should be used. The goal of this discussion is to help you make good decisions about what tools to use and when, and to offer guidance about how to use them most effectively.

SharePoint 2010 Workflow Structure, Security Rules, and Automation Features

Before you examine specific scenarios, it is important that you understand how a SharePoint workflow is structured. This section discusses what components, or building blocks, are used to create a SharePoint workflow; what security rules apply to workflows; and what new features in SharePoint 2010 can increase your options for automating key business processes. The section then describes an example scenario where a workflow can be built and extended to improve business productivity.

Workflow Components

There are four key components of a workflow:

Events An event is "something that happens" that causes a workflow to do something. The most common sort of event is the initiating event—that is, the event that starts a workflow. There are several ways in which workflows are started: when a user makes a manual request (such as clicking Start Workflow), when an item (such as a list item or a site) is created, or when an item is changed. When a workflow is initiated, you can give the user a form to collect data for executing the workflow.
Steps Steps are the primary means of structure and organization within a workflow. A step contains one or more actions and, optionally, one or more conditions. Both the structure and number of steps are largely up to you—you can create a "one-step" workflow in which that single step contains a large list of actions. However, it is usually better, from an organizational perspective, to separate additional steps.
Conditions As you think about workflows, you likely will encounter statements such as, "If the amount of the purchase is greater than $10,000, executive approval is required." This kind of conditional logic is at the heart of how SharePoint workflows process information. To enable this kind of "if-then-else" logic in your workflows, you add conditions. A condition is a statement that, if true, tells the workflow engine to execute an associated task or group of tasks.

SharePoint Designer 2010 has several built-in, predefined conditions that support common workflow scenarios. You can use these conditions to help rapidly develop and deploy SharePoint workflows. For a list of conditions that are available in SharePoint Designer 2010, see SharePoint Designer 2010 Built-in Conditions later in this article.
Actions If steps are the "where" and conditions are the "when," actions are the critical "what" piece of the workflow story. An action can be anything—from working with an item associated with the workflow, to sending email to a certain participant, to updating another data repository.

You can build custom actions (as discussed in Extending SharePoint Designer Workflows Using Custom Activities later in this article); but SharePoint Designer 2010 includes a comprehensive set of actions that enables you to build even complex examples of most common business processes in SharePoint 2010. For a list of built-in, predefined actions that are available in SharePoint Designer 2010, see SharePoint Designer 2010 Built-in Actions later in this article.

Workflow Security Model

Because SharePoint 2010 is an enterprise-class collaborative system, security and user context are a critical piece of any solution, and workflows are no exception. The following are some important rules of workflow security:

Workflows run as the initiator In general, the security context of all actions that a workflow performs is that of the initiator—that is, the user who started the workflow by manually triggering it or performing another action that caused it to start automatically.
Impersonation steps run as the author Sometimes, your initiators cannot perform a required task in a workflow, either because they do not have access to the task or because you do not want them to act on the task. In these cases, you can enclose the task in an impersonation step, which causes the task to be executed as the user who created the workflow. (For more information about impersonation steps, see the next section.)
Workflows are site-scoped Without further customization, you can access items (such as lists and libraries) only within the site to which a workflow is associated.

New Workflow Options in SharePoint 2010

SharePoint 2010 improves on the workflow system found in earlier versions. Specifically, new options for structuring workflows are available to increase the number of scenarios that can be automated:

Parallel branches Workflow actions can be configured to run in serial or parallel configurations. When you run actions in serial, an action starts only when the previous action is complete. When you run actions in parallel, all actions within a parallel block start at the same time.

For a parallel branch, the workflow proceeds down one of two parallel paths. For example, if a reviewer approves a document, the workflow moves the approved document to a specific document library, and then sends an email message to the entire team to notify them of the approval. If the reviewer rejects the document, the workflow notifies the document author of the rejection. In either case, the workflow then reaches its end and the process is complete.
Nested steps Steps group conditions and actions so that one set of rules can be evaluated and performed before a second set. In earlier versions of SharePoint workflows, steps were a single-level structure, containing conditions and actions. In SharePoint 2010, you can nest or add steps within steps. Figure 1 shows the process of using nested steps in a conditional block.

Figure 1. Nested steps in a conditional block

Nested steps are a good way to improve the organization of your workflow. For example, a workflow might have many actions in a step that does not use conditions. In this case, you can separate the actions into steps to better organize them. Here, the rules in one step are processed to conclusion before moving to the next step, so be sure to group in the same step the rules that are necessary to effect the specific actions that you want.
Impersonation steps As discussed earlier in Workflow Security Model, workflows generally run in the context of the user who starts the workflow. SharePoint 2010 introduces impersonation steps, where sections of the workflow can be run under the identity of the workflow’s author instead of the identity of its initiator. Impersonation steps are especially useful in approval and publishing scenarios, where the people who submit content for approval and those who approve the content have different permissions.

For example, if the workflow’s author does not have access to a particular document library that contains sensitive information, a standard workflow cannot perform any actions that correspond to the library; however, with an impersonation step, the workflow can gain access while still protecting information from people who do not have access rights. From a security standpoint, this is an important and useful feature because it enables proper least privilege-style security and does not require open access just for the sake of workflows.

Impersonation actions can also be particularly useful in automating a site administrator’s tasks. Examples include a workflow that automatically assigns permissions to users or a workflow that maintains lists.

Note

Impersonation steps can be added only to the root of a workflow and cannot be nested in another step.

Example SharePoint Workflow Scenario: Process Workflow for Recruiting and Hiring New Employees

Now that you have some background about SharePoint workflows, let’s examine an example of one that you could build and extend in a real business scenario.

For this example, you are assuming the role of a Senior Analyst in the Human Resources (HR) group of Contoso Coffee, a midsized but growing company that operates retail cafes and produces a range of products for other channels. Your role supports the HR Director, and you are the group’s process expert. You have used SharePoint frequently over the last several years for a variety of purposes: document management, collaboration, and intranet site creation. In your group, you own several team sites and drive people to use their capabilities.

Contoso currently has a standard process for recruiting and hiring new employees, but it is fairly manual and people-intensive. Although this process is time-tested and has served the company well in the past, it is becoming a bottleneck for the accelerated pace of growth at Contoso. The IT department recently completed upgrading the SharePoint environment to SharePoint 2010, and you are eager to exercise this new tool to automate the recruiting and hiring process.

Of course, your time and budget are limited. Therefore, you must build solutions that not only work properly, but also are as efficient, cost effective, and robust as possible.

Using Built-in Workflows in SharePoint 2010 to Streamline a Business Process

This section examines built-in workflows. It presents a common business process problem—and its solution—in the context the Contoso Coffee example in the previous section. It also discusses the details of built-in workflows, including features and tools, common scenarios, usage guidance, and constraints.

Problem: How to Streamline a Business Process

After some careful analysis, you confirm a key problem with the current manual recruiting and hiring process: getting approval from the right people for new job requisitions. Getting approval is time-consuming and, at times, confusing, with multiple back-and-forth discussions often occurring over email.

Previously, you started to address this problem by using a SharePoint list for job requisitions. Although this has helped ensure that people access data from a "single source of truth," it has not streamlined the approval process itself.

SharePoint 2010 Built-in Features and Tools

SharePoint 2010 includes several predefined workflows that are installed as features and are ready to use immediately after deploying the product. After you activate a predefined workflow for your site collection, you can add the workflow to any list, library, or content type on the site.

As a site owner, you can configure built-in workflows by completing forms that contain choices about workflow setup and participants for a particular list or content type. On the Server ribbon, click Workflow Settings, as shown in Figure 2.

Figure 2. Workflow Settings button

Workflow settings button

Figure 3 shows the form that you use to configure your built-in workflow.

Figure 3. Workflow choices form for configuring a built-in workflow

Workflow choices form

Six Scenarios for Built-in Workflows in SharePoint 2010

There are six workflows built into SharePoint 2010. Each represents a particular type of scenario, as shown in Table 1.

Table 1. Scenarios for built-in workflows in SharePoint 2010

Scenario	Description
Collect Feedback	Routes a document or item to a group of people for feedback. Reviewers can provide feedback, which is then compiled and sent to the person who initiated the workflow.
Approval	Routes a document or item to a group of people for approval. By default, the Approval workflow is associated with the Document content type; therefore, it is automatically available in document libraries. The Approval workflow is a staged approval model; that is, the first set of approvers undergoes the review and approval process, then the next set, and so on.
Disposition Approval	Manages document expiration and retention by letting participants decide whether to keep or delete expired documents. The Disposition Approval workflow supports records management processes and is intended for use primarily in a Records Center site.
Collect Signatures	Routes a document that was created in a Microsoft application to a group of people to collect their digital signatures. Participants must complete the signature task by adding their digital signatures to the document in the relevant client program.
Three-State	Designed to track the status of a list item through three states (phases). This workflow 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 two transitions between the states.
Publishing	Supports the SharePoint publishing infrastructure and is available only on sites that have the publishing features enabled. It is similar to the Approval workflow, with some modifications to fit the publishing context.

Note

The Three-State workflow is available in SharePoint Foundation 2010 and SharePoint Server 2010. The Collect Feedback, Approval, Disposition Approval, Collect Signatures, and Publishing workflows are available only in SharePoint Server 2010.

Guidance for Using SharePoint 2010 Built-in Workflows

To follow the guiding principle of implementing a low-cost, low-complexity workflow solution that meets the needs of the process that is being automated, do not overlook SharePoint 2010 built-in workflows. In fact, you should use built-in workflows whenever more detailed customization is not required. These workflows do not require any rich-client tools—they are configured entirely within the web user interface (UI). Also, no IT involvement is required to configure or maintain them.

Specifically, when you work with built-in workflows, do the following:

Use two new features in the SharePoint 2010 Approval workflow to increase flexibility in your approval processes: Reassignment, which enables approvers to delegate their tasks to another user on-the-fly, and Multiple Assignment Stages, which lets you create multiple steps of serial or parallel approval without manually building the workflow.
Consider automatically starting workflows when items are added or edited. Workflows that are manually initiated can be intimidating for users who are unfamiliar with SharePoint and process automation.
For workflows that must be initiated by user action, consider adding custom options to your list’s List Item menu—the drop-down menu that appears when you point to or select a list item (see Figure 4). This can help improve the visibility and selectability of your workflows. You can add these items, known as Edit Control Block (ECB) items, in SharePoint Designer without having to write code or change XML configuration files.

Figure 4. Engaging the List Item menu in SharePoint 2010
If a built-in workflow is close to, but not exactly, the process you want, you can open certain workflows (such as Approval) in SharePoint Designer and use them as the basis for custom workflows (see Building Visual Studio Workflows later in this article), as shown in Figure 5.

Figure 5. Using a workflow in SharePoint Designer as the basis for a custom workflow

Constraints to Built-in Workflows in SharePoint

Built-in workflows, especially with enhancements in SharePoint 2010, are very configurable. However, you can do only so much customization by using configuration options alone. Certain common limitations will probably lead you to explore more complex customization options, as shown in Table 2.

Table 2. Common constraints to built-in SharePoint workflows

Constraint	Description
Flow and logic are preset	The workflow proceeds as it was originally designed. Although you can change some details about how the workflow behaves, you cannot control them all. For example, you cannot route approvals to different people based on a condition that depends on information about the item.
Cannot add new activities	For example, you cannot tell a built-in workflow to modify a list item after an approval occurs, or to send a custom-designed email message to a designated person. However, you can use a built-in workflow as a template for a custom workflow.
Cannot interact with external systems	Built-in workflows generally operate only within a list, library, or site.
Cannot reuse (configured) workflows across lists	Although workflow templates are available to any sites in your farm on which their features are activated, they must be configured individually on each list, library, or content type to which you associate them.

Solution: Use the Built-in Approval Workflow to Streamline the Business Process

You decide that the Contoso Coffee recruiting and hiring process can benefit significantly from using the built-in Approval workflow. You browse to your job requisitions list, edit its settings, and add a workflow. Because you want this workflow to apply to all new items, you choose to start the workflow whenever a new item is added to the list, as shown in Figure 6.

Figure 6. Choosing to start the workflow whenever a new item is added

Start workflow when new item is created

Next, you configure the workflow’s association settings. The main issues to decide are (1) who the approvers are, and (2) in what order and by what method will they be asked for approval. Here, you have two stages. First, Amy and Andy, the Recruiting Managers, must approve the requisition. This is a parallel approval, because both tasks can occur at once. After this stage is complete, Frank, the Chief Operating Officer (COO), has final approval rights (see Figure 7).

Figure 7. Designating a workflow’s association settings

Designating workflow association settings

Similarly, you configure other properties about the workflow, such as due dates and task duration. After you complete this form, the workflow is ready for use.

For more information about adding a built-in workflow, see Using the Workflows in SharePoint 2010.

Using SharePoint Designer 2010 to Extend and Manage Workflows

This section examines the use of SharePoint Designer 2010 for extending and managing workflows. As previously, this section presents a common business process problem and its solution in the context the Contoso Coffee example. Specifically, it focuses on the features and tools, common scenarios, usage guidance, and constraints that are related to using SharePoint Designer for enhanced workflows.

Problem: How to Add More Customization to SharePoint Workflows

Your Approval workflow for the recruiting and hiring process at Contoso Coffee achieves mixed results. It reduces email volume, but it does not entirely succeed at getting the right people engaged at the right time in the process.

Contoso must route approvals to different people based on the expected salary for the job requisition. In addition, you need to automate the posting of the position within the company by adding it to another SharePoint list that is used to communicate job openings. Finally, you must ensure that email notifications and logs are kept.

Specifically, you have gathered the following requirements:

All requisitions require approval from the Recruiting Manager and Hiring Manager (who is different for each requisition).
If the requested salary is greater than $100,000, COO approval is also required.
Email notifications must be sent to the submitter after approval or rejection.
After all approvals, the requisition must be posted to the company’s internal jobs site (add a list item).

Solution: Use SharePoint, SharePoint Designer, and Visio Features and Tools to Extend and Manage SharePoint Workflows

Several features and tools are provided to help you quickly and easily extend and manage SharePoint workflows. This section discusses five of the most important:

No-code workflows
Reusable workflows
SharePoint Designer 2010
Error checker
Visio Premium 2010

No-Code Workflows in SharePoint 2010

SharePoint 2010 enables the concept of the declarative workflow. The term "declarative" means that instead of being written in procedural or object-oriented code, these workflows are declared in an XML schema known as Extensible Application Markup Language (which is, for historical reasons, abbreviated XOML in the world of workflow). Fortunately, SharePoint Designer 2010 generates this XOML for you out of predefined building blocks (such as events, conditions, and actions) and predefined conditional logic that links those blocks together.

You can create workflows for a variety of tasks by using available actions. A key differentiating factor among workflows in SharePoint is to which SharePoint object each workflow is associated. Because design is often guided by which kind of item is being operated upon, this property is so critical that it is often useful to think about types of workflows, as follows:

List and library workflows Usually, a workflow applies to a specific repository of items—either documents in a document library or a SharePoint list that holds some kind of structured data. A common application of a list workflow is to enable a process for approving documents.
Reusable workflows A workflow might be intended for a specific type of content (or multiple types of content). Content types are a key functionality in SharePoint 2010 and are used across the platform for controlling properties and metadata about particular kinds of content. Workflows can be built to accommodate a single content type, or they can be more generic and be associated with a content type within a list or library or with a site content type that can be used across multiple lists.
Site workflows Workflows can be used with SharePoint 2010 sites. This feature is especially useful when the workflow implements a process that does not start as a result of a list item or document and must be initiated manually through the SharePoint UI or SharePoint API. It is also helpful if the workflow must monitor actions that occur in several places across the site.

Reusable Workflows in SharePoint 2010

Even with no-code development, it can take substantial time and analysis to build workflows. In earlier versions of SharePoint, workflows applied to a single list or library only. In SharePoint 2010, you can create list workflows that have full reusability and exportability. These reusable workflows do not rely on a specific list but can be associated with any list. Further, the workflow design can be reused and associated with multiple lists. In addition, you can use the Save as Template command to create a SharePoint solution package (,wsp file) that contains a reusable workflow; this workflow can be moved to another SharePoint server or to Microsoft Visual Studio 2010.

Workflow Editor in SharePoint Designer 2010

SharePoint Designer 2010 is the rich client interface to SharePoint Server 2010. With SharePoint Designer, you can manage, extend, and customize SharePoint sites. SharePoint Designer has several features in common with Microsoft Office applications, including the ribbon UI and editing capabilities.

The SharePoint Designer workflow editor can introduce a hierarchical, sequential, and linear view of the workflow that you are creating. The workflow is broken down into a set of steps, each of which can contain a number of conditions and actions, as shown in Figure 8. By arranging the needed steps, adding actions, and "filling in the blanks" with specifics, you can easily define the logic that makes up your desired workflow.

Figure 8. Creating workflow steps, actions, and conditions in SharePoint Designer

Creating workflow steps, actions, and conditions

Error Checker in SharePoint Designer 2010

Workflows that use all capabilities available in SharePoint 2010 can quickly become complex. Building a workflow that the system can execute successfully requires you to design the flow of the process correctly, and also ensure that all conditional logic makes sense, all parameters are correctly completed, and so on. SharePoint Designer 2010 includes an error checker (see Figure 9) that can help locate such errors as you build the workflow, instead of at run time, when real data is at stake.

Figure 9. Check for Errors button in SharePoint Designer 2010

Check for Errors button

For example, if you have not entered data that a condition or action requires (a common omission when looking at a page full of steps), SharePoint Designer 2010 highlights the error in context (see Figure 10) so that you can easily find and fix it.

Figure 10. Example of how SharePoint Designer 2010 highlights errors in context

Highlighting errors in context

After all errors are fixed, clicking Check for Errors shows that the workflow is ready for publishing, as shown in Figure 11.

Figure 11. SharePoint Designer message that indicates an error-free workflow

Error-free workflow message

Drawing Template for SharePoint 2010 Workflows in Visio Premium 2010

The SharePoint Designer view is a great way to create, edit, and configure workflows, but being able to visually define a workflow and its related information and process flows is often important. Microsoft Visio Premium 2010 can simplify the task of creating these workflows without the need for specialized technical resources. Visio Premium 2010 includes a drawing template for SharePoint 2010 workflows. The shapes in this drawing template include the workflow building blocks that are available in SharePoint workflows. You drag these shapes onto a drawing and create a flowchart that represents the workflow. Then, the drawing is exported to an interchange file that is brought into SharePoint Designer 2010 for configuration and deployment.

Note

This capability requires SharePoint Server 2010 and Visio Premium 2010.

In addition, if Visio Services (a SharePoint 2010 Enterprise feature) is available, you can use a Visio diagram representation to visualize in-process workflows while they are running, including information about workflow progress and task assignments.

The following are other tips for effectively using Visio Premium 2010 with SharePoint Designer 2010:

Some business analysts can better design processes visually than hierarchically. In this case, allow the analyst to create the process flow first in Visio and export it to SharePoint Designer to fill in details. This visual capability can help engage the right people in automating business processes.
Even if SharePoint Designer is used to build the workflow, you can export the workflow to Visio for documentation and communication. Visual depictions of workflows can be useful for reviewing with business specialists, especially executives who may not be familiar with the SharePoint Designer view. Process diagrams can also be important artifacts of projects, and Visio drawings are an excellent way to create and store them. In fact, you can brand drawings that are created from workflow interchange files by adding custom shapes, graphics, and other modifications to the visual layout of the drawing.
Although visual process design is, in some ways, simpler than the full functionality of SharePoint Designer, creating a workflow still requires knowledge about how SharePoint workflows are constructed. Remember that the workflow interchange functionality is not a universal solution for converting any Visio drawing into a workflow.
Visio does not have a mechanism for modeling the SharePoint Designer step structure. Under some circumstances, step data can be lost when round-tripping between SharePoint Designer and Visio. You should use caution in this situation.
Visio does not provide detailed information about custom activities that may be added to the workflow.

Common Scenarios for No-Code Workflows in SharePoint 2010

With the previously mentioned building blocks, no-code workflows offer an almost completely clean slate for building workflows for any process that can be documented. Table 3 shows several common scenarios for which no-code workflows are especially suitable.

Table 3. Common scenarios for no-code workflows in SharePoint 2010

Scenario	Description
Complex, customized versions of the built-in workflows	Many of the processes that benefit from custom workflows involve the same basic requirements that built-in workflows were designed to satisfy—but with different or more complicated details. For example: Document review and approval Because document management is a SharePoint strength that is commonly used, you likely will be faced with the need to enable review and approval processes around documents that are stored and managed in SharePoint 2010. Many organizations use these kinds of workflows to approve internal documents, such as policies and procedures. Other types of teams may need approval processes for project deliverables that will be presented to clients. Collaboration Collaborative workflows are used to help multiple people or groups work together on a particular document or task. These workflows resemble approvals in that documents are routed among people, but they differ in that the process is usually less defined. For example, a web development firm might use a collaborative workflow to specify a customer’s site. An information architect can create the site map and structure, and route the document to the designer for visual layout. The designer can route the proof to the copywriter for content, and then it can go to client management for approval—all based on the needs of that particular task.
Administrative processes	Workflows do not have to be document-centric. Instead, they are often used to improve the administrative functions of a company or team. One very common example of this kind of scenario is the expense report.
System workflows	The site-associated workflow lends itself to helping automate tasks that are involved with managing SharePoint sites. For example, a site disposition workflow might be created for project sites so that when a particular project is completed, its documents and other content are archived and disposed of appropriately.

Complex, customized versions of the built-in workflows

Many of the processes that benefit from custom workflows involve the same basic requirements that built-in workflows were designed to satisfy—but with different or more complicated details. For example:

Document review and approval Because document management is a SharePoint strength that is commonly used, you likely will be faced with the need to enable review and approval processes around documents that are stored and managed in SharePoint 2010. Many organizations use these kinds of workflows to approve internal documents, such as policies and procedures. Other types of teams may need approval processes for project deliverables that will be presented to clients.
Collaboration Collaborative workflows are used to help multiple people or groups work together on a particular document or task. These workflows resemble approvals in that documents are routed among people, but they differ in that the process is usually less defined. For example, a web development firm might use a collaborative workflow to specify a customer’s site. An information architect can create the site map and structure, and route the document to the designer for visual layout. The designer can route the proof to the copywriter for content, and then it can go to client management for approval—all based on the needs of that particular task.

Administrative processes

Workflows do not have to be document-centric. Instead, they are often used to improve the administrative functions of a company or team. One very common example of this kind of scenario is the expense report.

System workflows

The site-associated workflow lends itself to helping automate tasks that are involved with managing SharePoint sites. For example, a site disposition workflow might be created for project sites so that when a particular project is completed, its documents and other content are archived and disposed of appropriately.

Usage Guidance for No-Code Workflows in SharePoint 2010

Although it is more involved than configuring a built-in workflow, building no-code workflows can still be a low-cost, low-complexity, and low-management approach to process automation. You do not have to write code, and the IT department does not need to deploy anything. To maximize your investment in these workflows, consider doing the following:

When possible, design workflows that are associated with a content type to enable reuse across multiple lists or libraries. The content-type-associated workflow is a very powerful tool that can multiply the usefulness of a single workflow as compared to using it only for a single list.
Export workflows from SharePoint Designer 2010 as solution packages (.wsp files). These packages can then be deployed quickly to the solution galleries of other sites, enabling basic life cycle management and helping drive reusability.
Use the impersonation step, a feature that is new to SharePoint 2010, when you need to perform an action or set of actions as the workflow author instead of the user who initiated the workflow. This can be useful when, for example, you need a workflow to add data to a list that you do not want all users to be able to access.
SharePoint Designer 2010 includes an error checker. Always be sure to run this feature when you create or modify a workflow to catch errors in consistency or logic.
Always review workflows with business specialists to ensure that the process makes sense and that business requirements were transferred to the tools correctly. Automated error-checking is useful, but it cannot expose more fundamental problems that relate to the underlying logic of a workflow.
When you use Visio Premium 2010, roundtrip between SharePoint Designer and Visio to use the tool that is best for the task.

Constraints to No-Code SharePoint Workflows

No-code workflows provide a powerful, flexible way to automate more complex business processes. However, some constraints do exist, as shown in Table 4.

Table 4. Constraints to no-code SharePoint workflows

Constraint	Description
Finite number of building blocks	You are limited to using the building blocks that are either included with SharePoint 2010 or installed by an administrator. Although these encompass most of the elements in a workflow, if you need something new, you must create a custom activity.
Cannot model certain kinds of logic	Declarative workflows are sequential in structure. They cannot model certain kinds of logic. Specifically, some processes lend themselves to a "do-while loop," where some part of the workflow should be repeated until a condition is satisfied or a list of items is worked through. This kind of loop requires a Visual Studio workflow. An additional structure that is supported in Windows Workflow Foundation, but not in no-code workflows, is the state machine workflow, For more information, see Creating SharePoint 2010 State Machine Workflows in Visual Studio 2010.
Potential action errors with solution packages	When you package workflows as solution packages for use in other sites, you may find that actions that interact with other lists do not work correctly; here, you must edit the workflow to reestablish the relationships.
Cannot interact with external systems	Without extension, workflows cannot "call out" to other systems. They are limited to operating within the SharePoint environment. When interactions with external systems are required, you should explore BCS or custom activities.
Cannot write procedural code within SharePoint Designer 2010	There is no facility for you to write procedural code (such as C#) to create small extensions directly within SharePoint Designer 2010.
Potential confusion with impersonation steps	Impersonation steps potentially can cause confusion when users expect the "modified by" information about a list item to correspond to the workflow-initiating user. Remember that any actions performed within an impersonation step will be in the context of the user who published the workflow.

Solution: Create a No-Code Workflow Using Visio and SharePoint Designer

To refine the Contoso Coffee recruiting and hiring process, you use Visio Premium 2010 and SharePoint Designer 2010 to create a no-code workflow to model the approval processes. You use the built-in components that are available in SharePoint to accomplish the routing and notification requirements, making sure to add conditions for new routing rules. After the workflow is complete, you remove the existing Approval workflow and associate the new custom workflow to the job requisitions list, as shown in Figure 12.

Figure 12. Workflow for the Contoso Coffee recruiting and hiring process

Recruiting and hiring workflow

Extending SharePoint Designer Workflows Using Business Connectivity Services (BCS)

This section discusses how to extend SharePoint Designer workflows using BCS. The discussion continues around a sample business problem and solution for Contoso Coffee. In particular, this section reviews the features and tools, common scenarios, usage guidance, and constraints for using BCS with more complex workflows.

Problem: How to Integrate LOB System Data

The new recruiting and hiring approval process at Contoso Coffee is working well. In fact, management is so impressed that they want to use workflow to remove another manual step: adding the requisition to the Contoso Human Resources management system (HRMS).

The company’s HRMS is a legacy line-of-business (LOB) system. You have to add some information found in the job requisition list to the system. To help you do this, the HR IT group has provided a Microsoft SQL Server database table-based interface.

Using BCS to Extend Workflows

BCS is a key tool for extending workflows for SharePoint 2010.

BCS can help you integrate data from other LOB systems and databases. BCS is a very powerful and flexible tool, enabling organizations to use SharePoint Designer 2010 to create connections to surface external data sources and write data back to these sources. BCS creates external content types and lists to reference external data. These external content types and lists can be accessed by SharePoint workflows. Figure 13 provides an overview of BCS.

Figure 13. High-level view of Business Connectivity Services

Business Connectivity Services

You have already seen how to use SharePoint Designer 2010 to create workflows that do not use code. The activities that are used to create these workflows, including Create List Item, Update List Item, and Delete List Item, also support external lists that are created by BCS. As a result, workflows can work with data from other systems. For example, you can create a workflow so that when a customer sends a change-of-address form through email, the customer relationship management (CRM) system updates the customer’s information without needing to store it in SharePoint 2010 and later sync it back to the CRM system.

In addition, you can use other activities, such as Set Workflow Variable, with external list data to create a pick list or an item from a SharePoint list. For example, you can use customer information stored in the CRM system as selectable items in a workflow form. This can help ensure integrity when people enter customer information, because there is no need to replicate the data in the SharePoint workflow. List workflows can be started automatically when a list item is added or changed, and they can contain conditional logic for associated actions. Site workflows do not require a trigger to start.

Common Scenarios for Integrating BCS in SharePoint Workflows

By far, the most common scenario for integrating BCS is to enable a workflow to interact with other business systems or databases. This can be useful in many individual cases.

Workflows can consume data from BCS to be used as parameters for conditional logic. For example, a workflow may need to look up information about an employee from an enterprise resource planning (ERP) system to determine whether a certain type of approval for a task is required. Workflows can also write data to or modify data in external systems through BCS. An example for both of these methods is a vacation request workflow where a workflow queries the payroll system to determine whether an employee has vacation time available, gains necessary management approval, and then updates an item in an external list linked to the payroll system to record the time off.

BCS Usage Guidance for SharePoint Workflows

After an external list is created, BCS removes much of the complexity and risk involved in working with external systems from your workflows. You generally can treat external lists like any other list that can be manipulated using the built-in Create, Modify, Delete, and Get actions. There are, of course, some specifics to be aware of when integrating BCS into workflows:

Use the Set Workflow Variable action to get data from external lists.
Use the Create and Update List Item actions to edit external lists.
Limit the amount of data consumed from external lists in your workflows. Reading multiple values from the same external list item does not cache the item. Therefore, the activity must call BCS for each column that is read. For example, reading 10 properties in a list of 2,000 items causes 20 calls to the Business Data Connectivity (BDC) service and retrieves 20,010 items from the external system.

Constraints to Using BCS to Extend SharePoint Workflows

Extending workflows by using BCS can further enhance your ability to automate complex, multiuser business processes. Still, it is a good idea to be aware of certain limitations with this approach, as listed in Table 5.

Table 5. Constraints to using BCS to extend SharePoint workflows

Constraint	Description
No direct association with external lists	Workflows cannot be associated directly with external lists, although they do work with external lists. For example, you can create a site workflow or a list workflow on a SharePoint list (such as a document library) and have it read or update from an external list. You can also use an external list item as a destination for a task process in SharePoint Designer 2010; however, the link to the task will not display a title for the external list item.
Potential confusion about who is making changes	Because access to the external system is always through one account, you might lose track of who is making changes. To address this issue, you can have the workflow pass the SPUser name to a column on the external list or to a custom activity that uses the BDC APIs. Note This scenario is presented for information only and should not be used as a security feature.
BDC service account	Workflows that access the Business Data Connectivity (BDC) service always run as the service account—which is usually the Internet Information Services (IIS) application pool account that is assigned to the web application in which the workflow is deployed. This is true even under an impersonation step. This means that the BCS connection must be configured to use credentials from the Secure Store Service to allow the service account to impersonate an account with access the back-end store or service. For more information, see How to: Use Credentials from the Secure Store Service to Connect to the External System.
Limitations with a large number of rows or columns	If you have to work with a large number of rows or columns, the built-in activities are not suitable. You could create a custom action to work more directly with BCS and bypass the limitations of the default actions.

Solution: Create a BCS External List to Use with SharePoint Workflows

With some guidance from your IT colleagues, you configure a BCS external list to enable interaction with the external Contoso Coffee HRMS. After you create the external list, you just add another Create List Item activity that uses the external list with the existing workflow to complete the integration.

Extending SharePoint Designer Workflows Using Custom Activities

This section examines how developers can create custom activities to further extend SharePoint Designer workflows. The Contoso Coffee example provides a business process problem that can be solved with a highly customized workflow. To provide a comprehensive overview of custom workflow activities, this section examines related features and tools, common scenarios, usage guidance, and constraints.

Problem: How to Interact with Web Services

After approvals, you send the position to Contoso’s third-party, outsourced recruiting provider for posting on the company’s external website. The recruiting vendor has provided a Windows Communication Foundation (WCF) web service to interface with its system. You need to send some of the data found in the requisition list to this service, following proper security and efficiency practices.

Features and Tools for Creating Custom Activities

Although much can be done with SharePoint Designer 2010 and Visio Premium 2010, you likely will encounter situations where you must do something that cannot be modeled easily in a SharePoint workflow. This is often a "last 10 percent" problem, where one specific but important requirement jeopardizes an otherwise highly useful workflow. To bridge this gap, you need one of the most important features in the SharePoint workflow system: the ability to create custom workflow activities to extend the kinds of things that workflows can do.

Custom Activities to Build More Complex SharePoint Workflows You can create custom activities to help end users build more complex workflows with SharePoint Designer 2010. When built-in workflow activities do not meet specific business requirements, custom activities become especially useful. Available in Office SharePoint Server 2007 and Windows SharePoint Services 3.0, this feature was continued in SharePoint 2010. This means that after a custom activity is created, it can be used inside SharePoint Designer. For example, you can create a custom activity that adds relevant users and their permissions to a site. You can access the custom activities feature in SharePoint Designer on the Action menu, under the My Custom Activities section.

Because a no-code workflow can be extended with a specific activity or set of activities, your investment in costly development can be focused on where it is most valuable. Custom activities are reusable and, when they are deployed, you can use them in workflows across all sites in your SharePoint farm.

Sandboxed Activities vs. Full-Trust Activities for SharePoint Workflows As with almost all SharePoint 2010 development efforts, the choice of whether to use a sandboxed activity or an activity that requires full trust is important. Sandboxed activities provide some significant advantages. Namely, they can be deployed to a site collection by a site owner entirely through the administrative web UI; it is not necessary to involve IT administration. The sandbox also provides some measure of safety, preventing code from doing anything that might affect other areas of the system.

Yet, sandboxed activities are limited in some key ways—mainly, they are not allowed to make network calls to other servers, and access to the SharePoint APIs is limited. For more information about these limitations, see the Constraints to Using Custom Activities to Extend SharePoint Workflows section. For information about when to use either the sandboxed or full-trust approach, see the Usage Guidance for Creating Custom SharePoint Workflow Activities section.

Visual Studio 2010 Visual Studio 2010 includes significantly enhanced tooling (as compared to earlier versions) for easily creating, packaging, and deploying code to SharePoint 2010.

Common Scenarios for Customized SharePoint Workflows

Four of the most common scenarios for using highly customized workflows are shown in Table 6.

Table 6. Common scenarios for customized SharePoint workflows

Scenario	Description
Interaction with an LOB system	It might become necessary to interact with an LOB system (such as an ERP or CRM application) from a workflow in a more complex way than is possible with BCS.
Custom activities	Custom activities are ideal for interacting with SharePoint 2010 itself in a way beyond what is possible using built-in actions. For example, you might have to provision a new workspace site as part of the process of collecting feedback or approval on a document.
Complex conditions	Some business processes require a complex set of conditions and actions that can be better represented with a small bit of custom code.
Utility activities	Custom utility activities can be created to provide a useful service that was not included with the product. For example, you can create an activity that replaces certain words in a string.

Usage Guidance for Creating Custom SharePoint Workflow Activities

Consider the following tips when you are creating custom SharePoint workflow activities:

After you write code, you make a de facto commitment to maintaining it. You also introduce additional risk into both your process and, potentially, the entire SharePoint environment. For this reason, you should exhaust all capabilities built into a SharePoint workflow before choosing to develop a custom action.
Limit the scope of what a single custom activity does. Activities should be seen as interchangeable, reusable pieces that are assembled into finished workflows—not as complete processes themselves. You can custom develop an entire workflow using Visual Studio 2010 (discussed in Building Visual Studio Workflows later in this article), or to encapsulate most of the workflow’s functionality in a single activity. However, this approach requires other considerations, such as the need for a development team to make changes. Properly designed workflow activities can reduce this burden and the risk it introduces.
Design custom activities with reusability in mind, and do not "hard code" too much about the details of the task being created. Allow workflow authors to configure sufficient properties to enable new use cases.
Although the workflow history list is a useful tool for surfacing information to workflow owners, be cautious about history list usage. Over-logging to the history list can cause performance and scale issues. In addition, events can "age off" of the list as more entries are added to it.
You must follow the coding standards for general .NET development, workflow development, and SharePoint object model development. For example, it is important to properly dispose of SharePoint objects, such as SPSite and SPWeb, after they are used.
Custom activities can be deployed as part of a sandboxed solution or in a fully-trusted farm solution. Sandboxed workflow actions are easier to deploy and manage; site owners install them in their sites’ solution galleries, which are centrally controlled and managed by IT. In addition, the sandboxed execution model provides another level of risk mitigation, preventing code in an activity from doing something unsafe or dangerous. When possible, you should develop activities in a way that is compatible with a sandboxed solution. However, some constraints apply that may require a farm-level deployment (see Table 7).

Constraints to Using Custom Activities to Extend SharePoint Workflows

There are two key constraints to extending workflows by using custom activities.

Table 7. Constraints to using custom activities to extend SharePoint workflows

Constraint	Description
Limitations in logic modeling	Custom activities extend no-code workflows instead of replacing them. Logic-modeling limitations (do-while loops, state machines, and the like) still apply, and if a break outside that box is necessary, you may need to think about developing a fully code-based workflow.
Restrictions of sandboxed solutions	Code (including custom activities) that is deployed in a sandboxed solution is subject to several restrictions. Significantly, code cannot make network calls outside the SharePoint farm on which it is deployed. Also, some parts of the SharePoint object model are not available. Full functionality requires code to be deployed to the server farm (or other established patterns for partially escaping the sandbox).

Limitations in logic modeling

Custom activities extend no-code workflows instead of replacing them. Logic-modeling limitations (do-while loops, state machines, and the like) still apply, and if a break outside that box is necessary, you may need to think about developing a fully code-based workflow.

Restrictions of sandboxed solutions

Code (including custom activities) that is deployed in a sandboxed solution is subject to several restrictions. Significantly, code cannot make network calls outside the SharePoint farm on which it is deployed. Also, some parts of the SharePoint object model are not available. Full functionality requires code to be deployed to the server farm (or other established patterns for partially escaping the sandbox).

Solution: Create a Custom Activity for a SharePoint Workflow

You can create a custom activity to call the recruiting vendor’s WCF service and post the required data. Because the service is hosted on the vendor’s Internet site, a sandboxed activity cannot be used due to the restriction on network access. You create a WSP package that contains a full-trust activity that must be deployed to the farm. The IT professionals who manage the SharePoint farm deploy the activity. Again, integration involves only adding this new custom activity to the existing workflow and configuring it.

Building Visual Studio Workflows

Finally, this section discusses using Visual Studio 2010 and basic code to create an increasingly complex workflow. Returning to the Contoso Coffee example, as demand for an even easier and faster HR process increases, so too does the need for a more powerful and flexible automated solution. To provide an overview of how Visual Studio 2010 can provide this solution, this section describes relevant features and tools, common scenarios, usage guidance, and constraints.

Problem: How to Handle More Complex Business Automation Needs

The newly customized approval process now handles the end-to-end task of creating a job posting at Contoso Coffee. However, there is also an organizational desire to automate more of the recruiting process. Instead of dealing with only new requisitions, a job now must be processed through several stages: submission, recruiting, hiring, and on-boarding.

Features and Tools for Building a Workflow

Although you can create and use almost any piece of functionality in no-code workflows, you still may encounter a situation where a process or requirement simply does not fit within the declarative workflow paradigm. In this situation, you require lower-level development, which Visual Studio 2010 can provide.

SharePoint Workflow Project Template Visual Studio 2010 includes a SharePoint workflow project template that lets a developer build workflows using the full capability and power of Windows Workflow Foundation. For example, a workflow may need to use a do-while loop to perform an activity while waiting for a condition (or, more likely, a set of conditions) to change. One commonly requested do-while loop is repeatedly notifying a person or group about the workflow status until an action is taken. As another example, you might determine that a state machine workflow based on events and transitions better models a business problem than a sequential SharePoint Designer 2010 workflow.

Flexible Forms Using ASP.NET Web Forms Technology Although much can be accomplished with standard Data Form Web Part forms and the Microsoft InfoPath Forms Designer, you may find that more customization would improve the user experience and process efficiency. Perhaps a form needs code to call to an external system to populate certain fields or to provide search engine-like suggestions while a user enters data. In a code-driven workflow, you use ASP.NET web forms technology to create custom forms that can perform almost any action and then, through the workflow API, interact with the underlying workflow.

Rich Debugging Tools in Visual Studio 2010 In terms of developer productivity, a critical feature of code-based workflows is the ability to fully debug a workflow on a step-by-step basis. (There is no similar debugger available for a declarative workflow.) Debugging a workflow using Visual Studio 2010 is similar to any other project—you can add breakpoints to workflow code and use stack tracing and other debugging tools for .NET projects. In addition, the workflow designer "lights up" a running workflow and displays visual indications of the state of various workflow components.

Visual Studio Workflow Deployment Deployment of code-based workflows is more complex than the SharePoint Designer-based process described earlier in this article. Still, both workflow development technologies share a common engine and description language (XOML), which permits some interoperability between the tools and ease of use for developers, administrators, and business process experts.

Like almost all SharePoint artifacts that developers create, Visual Studio 2010 workflow templates are packaged as Features. A Feature is an XML-defined set of customizations or functionalities that is deployed to SharePoint and activated on a particular site collection, site, web application, or farm. Also a standard in SharePoint 2010, workflow Features are generally deployed to farms as solution packages (.wsp files).

In Visual Studio 2010, the IDE handles most of the task of packaging developer-created elements, including workflows. When you create a SharePoint workflow project, some SharePoint-specific items are added to Solution Explorer. Visual Studio 2010 automatically sets up features and packages for the workflows added to the project, but you can customize the deployment, if necessary, as shown in Figure 14.

Figure 14. Adding features and packages automatically in Visual Studio 2010

Adding Features and packages automatically

While you are developing a workflow, you can right-click the project and select Deploy (see Figure 15) to have Visual Studio 2010 automatically connect to the development server; deploy the solution package; install and activate the necessary features; and, if configured, associate the workflow to your test list, library, or site. This means that you can rapidly execute change-deploy-test iterations without manually working with the SharePoint deployment infrastructure. When you are ready to deploy the workflow solution to the production environment, follow the same steps: deploy the package, install and activate features, and associate the workflow to a list.

Figure 15. Automatically executing a change-deploy-test iteration in Visual Studio 2010

Executing change-deploy-test iteration

The IT professionals who manage the SharePoint farm handle package deployment and feature installation by using Windows PowerShell or the administrative UI. After deployment is complete, you (as a site owner) just activate the feature in your site’s settings, as shown in Figure 16.

Figure 16. Activating a workflow Feature

Activating a workflow Feature

After the Feature is activated, you must associate it with a list, library, content type, or site before you can use it. You do this through the same association UI and forms that are used with the other types of workflows discussed earlier in this article.

Common Scenarios for SharePoint Workflows Created in Visual Studio

Visual Studio 2010 enables workflows with fully customized logic.

Table 8. Common scenarios for Visual Studio workflows

Scenario	Description
State machines	These workflows are modeled as transitions between states instead of steps that proceed sequentially. This is better for some processes that may not necessarily finalize the order in which the states are organized. These cannot be created using a purely declarative workflow.
Looping workflows	Some processes lend themselves to a do-while loop, where some part of the workflow is repeated until a condition is satisfied or a list of items is worked through. This kind of loop requires a Visual Studio 2010 workflow.
Complex, integrated system workflows that span multiple systems	These are vast system workflows that integrate various business systems together, using automation technology such Microsoft BizTalk Server. A SharePoint workflow can provide a front-end user interface for complex systems.
Advanced exception handling and audit	The built-in history-logging features provide insight into what happens within a workflow. When more particular logging, robustness, and error-handling requirements surface (such as when workflows are used to enable compliance scenarios), the advanced exception handling possible in programmatic workflow may be necessary.

Usage Guidance for Creating Visual Studio Workflows for Use in SharePoint

Consider the following tips when you are creating a Visual Studio workflow:

Although the workflow history list is a useful tool for surfacing information to workflow owners, be cautious about history list usage. Over-logging to the history list can cause performance and scale issues. In addition, events will "age off" of the list as more entries are added to it.
You must follow correct coding standards for general .NET development, workflow development, and SharePoint object model development. For example, it is important to properly dispose of SharePoint objects, such as SPSite and SPWeb, after they are used.
Use the solution package framework to deploy workflow templates to server farms.

Constraints to Building Visual Studio Workflows for Use in SharePoint

Table 9 lists the two key constraints to building a Visual Studio workflow.

Table 9. Constraints to building Visual Studio workflows

Constraint	Description
Cannot modify the workflow without writing code	A significant sacrifice is necessary to achieve the gains in flexibility that come with a Visual Studio workflow. The workflow becomes a compiled object that requires rebuilding and redeployment. This means that, without developer involvement, analysts and site owners do not have tools to modify workflows. This reduces flexibility and responsiveness and requires management of at least some level of the systems development life cycle.
Cannot be deployed in sandboxed solutions	Visual Studio workflow templates cannot be deployed in sandboxed solutions. They must be deployed with full trust to the server farm. This means that IT complexity increases, and that these workflows are not suitable for the cloud or hosted environments. You can import a SharePoint Designer 2010 workflow into Visual Studio 2010 and make modifications that are still sandbox-allowed, but customization options in this scenario are limited.

Cannot modify the workflow without writing code

A significant sacrifice is necessary to achieve the gains in flexibility that come with a Visual Studio workflow. The workflow becomes a compiled object that requires rebuilding and redeployment. This means that, without developer involvement, analysts and site owners do not have tools to modify workflows. This reduces flexibility and responsiveness and requires management of at least some level of the systems development life cycle.

Cannot be deployed in sandboxed solutions

Visual Studio workflow templates cannot be deployed in sandboxed solutions. They must be deployed with full trust to the server farm. This means that IT complexity increases, and that these workflows are not suitable for the cloud or hosted environments. You can import a SharePoint Designer 2010 workflow into Visual Studio 2010 and make modifications that are still sandbox-allowed, but customization options in this scenario are limited.

Solution: Write Code to Create the SharePoint Workflow

Again, you must write code that creates the workflow based on detailed requirements that you help gather. After the workflow is developed, debugged, and tested using developer tools (such as Visual Studio 2010), the IT professionals who manage the SharePoint farm deploy the workflow. Finally, you again use the association process to apply the state machine to your requisitions list.

Workflow Templates and Other Built-in Functionality in SharePoint Server and SharePoint Designer 2010

This section summarizes the built-in, predefined functionality in SharePoint Server and SharePoint Designer 2010 that supports common workflow scenarios.

SharePoint Server 2010 Workflow Templates

The following predefined workflow templates are available in SharePoint Server 2010.

Table 10. Predefined workflow templates in SharePoint Server 2010

Template	Description
Collect Feedback	Routes a document or item to a group of people for feedback. Reviewers can provide feedback, which is then compiled and sent to the person who initiated the workflow.
Approval	Routes a document or item to a group of people for approval. By default, the Approval workflow is associated with the Document content type; therefore, it is automatically available in document libraries. The Approval workflow is a staged approval model; that is, the first set of approvers undergoes the review and approval process, then the next set, and so on.
Disposition Approval	Manages document expiration and retention by letting participants decide whether to keep or delete expired documents. The Disposition Approval workflow supports record management processes and is intended for use primarily in a Records Center site.
Collect Signatures	Routes a document that was created in a Microsoft application to a group of people to collect their digital signatures. Participants must complete the signature task by adding their digital signatures to the document in the relevant client program.
Three-State	Designed to track the status of a list item through three states (phases). This workflow 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 two transitions between the states. Note This workflow is only supported on lists, not libraries.
Translation Management	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.
Issue Tracking	Routes an issue to team members for resolution. This workflow presents a webpage where the user enters new issues, such as customer complaints. As an issue progresses though different workflow states, the webpage changes to reflect appropriate events. (For example, the webpage might be closed when an issue is resolved.)

SharePoint Designer 2010 Built-in Conditions

The following conditions are available in SharePoint Designer for list and reusable list workflows.

Note

These conditions are reusable regardless of the list or content type with which the workflow is associated.

Table 11. Built-in conditions in SharePoint Designer

Condition	Description
If value equals value	Use this condition when you want to compare a value against another. Values can be static text, dynamic strings, and lookups to variables, context information, or SharePoint fields. In addition, the equal operator can be replaced by any logical operators. (For example, "If Variable: A week from Modified is greater than Today.")
If field equals value	Use this condition to compare what is entered into a field with a particular value. Values can be static text, dynamic strings, and lookups to variables, context information, or other SharePoint fields. The available options for fields depend on the content type, list, library, or site that the workflow is associated with. Note The field must be in the current item that the list or reusable list workflow is running on. (For example, "If Current Item: Modified is less than 1/1/2010 12:00:00 AM.")
Created by a specific person	This condition is initially displayed in a workflow step as, "If created by specific person." It checks whether an item was created by a specific user. The user can be specified as an email address or selected from Microsoft Exchange, Active Directory, or SharePoint users. (For example, "If created by Molly Dempsey.")
Created in a specific date span	This condition is initially displayed in a workflow step as, "If created between date and date." It checks whether an item was created between specified dates. You can use the current date, a specific date, or a lookup. (For example, "If created between 1/1/2010 and 1/1/2011 12:00:00 AM.")
Modified by a specific person	This condition is initially displayed in a workflow step as, "If modified by specific person." It checks whether an item was modified by a specific user. The user can be specified as an email address or selected from Exchange, Active Directory, or SharePoint users. (For example, "If modified by Molly Dempsey.")
Modified in a specific date span	This condition is initially displayed in a workflow step as, "If modified between date and date." It checks whether an item was modified between specified dates. (For example, "If modified between 1/1/2010 and 1/1/2011 12:00:00 AM.")
Person is a valid SharePoint user	This condition is initially displayed in a workflow step as, "If person is a valid SharePoint user." It checks whether a specified user is a member of the SharePoint site. (For example, "If Molly Dempsey is a valid SharePoint user.")
Title field contains keywords	This condition is initially displayed in a workflow step as, "If title field contains keywords." It checks whether the Title field for an item contains a specific word. You can either specify the keyword in the String Builder or insert a lookup to a field or variable. (For example, "If Title equals Apple \|\| Orange \|\| Pineapple.")

SharePoint Designer 2010 Built-in Actions

SharePoint Designer has several built-in, predefined actions that support common workflow scenarios.

Table 12. Built-in actions in SharePoint Designer

Action	Description
Add a Comment	Use this action to leave comments in the Workflow Designer for reference.
Add Time to Date	Use this action to add a specific time in minutes, hours, days, months, or years to a date; this action stores the output value in a variable.
Assign a Form to a Group	Use this action to assign a task to one or more participants or groups.
Assign a To-do Item	Use this action to assign tasks to participants; when they are finished, participants are prompted to click the Complete Task button on their task forms.
Check In Item	Use this action to check in an item that is checked out.
Check Out Item	Use this action to check out an item
Collect Data from a User	Use this action to assign tasks to participants, prompting them to provide information in custom task forms; when they are finished, participants are instructed to click the Complete Task button on their task forms.
Copy List Item	Use this action to copy a list item to another list.
Create List Item	Use this action to create a new list item in a specified list.
Delete Item	Use this action to delete an item.
Discard Item Checkout	Use this action if an item has been checked out and changed, but you want to omit the changes and check the original item back in.
Do Calculation	Use this action to perform a calculation, such as add, subtract, multiply, or divide, on two values; this action stores the output value in a variable.
Extract Substring from End of String	Use this action to copy n number of characters from the end of a string and store the output value in a variable.
Extract Substring from Index of String	Use this action to copy all characters starting from n in a string and store the output in a variable.
Extract Substring from Index with Length	Use this action to copy n number of characters starting from a particular character in a string; this action stores the output in a variable.
Extract Substring from Start of String	Use this action to copy n number of characters from the beginning of a string and store the output in a variable.
Find Interval Between Dates	Use this action to calculate the time difference—in terms of minutes, hours, or days—between two dates; this action stores the output in a variable.

Conclusion

As organizations try to "do more with less," they increasingly depend on the effective flow of information to make good decisions and improve worker efficiency. Using workflows to automate business processes can move your organization ahead of the curve in terms of growing strategically and improving productivity—all with reduced complexity, cost, and maintenance.

To really achieve the benefits of process automation, workflows should be built by the people who are experts in the processes. Workflows should also be created in a way that minimizes complexity, cost, and maintenance. SharePoint 2010 provides a tool set that lets you select the right approach for your process.

Built-in workflows, including the highly configurable Approval workflow, can provide much organization and power with little or no development effort. These workflows should not be overlooked; instead, they should be at the top of your mind when you have to apply automation to SharePoint lists and libraries.

When more customization is required, no-code workflows can be built in SharePoint Designer 2010 (and visualized with Visio Premium 2010). These workflows can also be published without developer or IT involvement. From a set of standard conditions and actions, you can create almost any sequential process. When connections to other systems are required, you should use BCS first. Further, when yet more purpose-built functionality is required, you can create largely reusable and safe custom actions to extend workflows in almost any way imaginable.

Finally, the full power of Windows Workflow Foundation is available with Visual Studio 2010 if the kinds of models possible with SharePoint Designer 2010 are not appropriate for your needs, and if an infrastructure is in place to develop, deploy, and maintain code.

Next Step: Learn More About Building SharePoint Workflows

Many of the tools and practices mentioned in this article are expansive topics on their own. Visit the resources listed in the next section to learn more about the specifics.

SharePoint Designer 2010, the main tool explored in this article, is a free download available on the SharePoint 2010 website. In addition, if your organization does not already use SharePoint 2010, and you want to explore building workflows, trial editions are available for download on the TechNet Evaluation Center.

Additional Resources

For more information, see the following resources:

Building Effective Workflows Using SharePoint Server 2010

Introduction to Building Workflows Using SharePoint Server 2010

Automating and Managing Human Workflow Using SharePoint 2010 Workflow Tools

Workflow Features in SharePoint 2010

SharePoint 2010 Workflow Structure, Security Rules, and Automation Features

Workflow Components

Workflow Security Model

New Workflow Options in SharePoint 2010

Example SharePoint Workflow Scenario: Process Workflow for Recruiting and Hiring New Employees

Using Built-in Workflows in SharePoint 2010 to Streamline a Business Process

Problem: How to Streamline a Business Process

SharePoint 2010 Built-in Features and Tools

Six Scenarios for Built-in Workflows in SharePoint 2010

Guidance for Using SharePoint 2010 Built-in Workflows

Constraints to Built-in Workflows in SharePoint

Solution: Use the Built-in Approval Workflow to Streamline the Business Process

Using SharePoint Designer 2010 to Extend and Manage Workflows

Problem: How to Add More Customization to SharePoint Workflows

Solution: Use SharePoint, SharePoint Designer, and Visio Features and Tools to Extend and Manage SharePoint Workflows

Common Scenarios for No-Code Workflows in SharePoint 2010

Usage Guidance for No-Code Workflows in SharePoint 2010

Constraints to No-Code SharePoint Workflows

Solution: Create a No-Code Workflow Using Visio and SharePoint Designer

Extending SharePoint Designer Workflows Using Business Connectivity Services (BCS)

Problem: How to Integrate LOB System Data

Using BCS to Extend Workflows

Common Scenarios for Integrating BCS in SharePoint Workflows

BCS Usage Guidance for SharePoint Workflows

Constraints to Using BCS to Extend SharePoint Workflows

Solution: Create a BCS External List to Use with SharePoint Workflows

Extending SharePoint Designer Workflows Using Custom Activities

Problem: How to Interact with Web Services

Features and Tools for Creating Custom Activities

Common Scenarios for Customized SharePoint Workflows

Usage Guidance for Creating Custom SharePoint Workflow Activities

Constraints to Using Custom Activities to Extend SharePoint Workflows

Solution: Create a Custom Activity for a SharePoint Workflow

Building Visual Studio Workflows

Problem: How to Handle More Complex Business Automation Needs

Features and Tools for Building a Workflow

Common Scenarios for SharePoint Workflows Created in Visual Studio

Usage Guidance for Creating Visual Studio Workflows for Use in SharePoint

Constraints to Building Visual Studio Workflows for Use in SharePoint

Solution: Write Code to Create the SharePoint Workflow

Workflow Templates and Other Built-in Functionality in SharePoint Server and SharePoint Designer 2010

SharePoint Server 2010 Workflow Templates

SharePoint Designer 2010 Built-in Conditions

SharePoint Designer 2010 Built-in Actions

Conclusion

Next Step: Learn More About Building SharePoint Workflows

Additional Resources

Additional resources