efore I can really describe what SharePoint and Workflow are together it's important to understand what is meant when I talk about workflow. Its most basic components are a stimulus—an event—and a response. The response can continue until the workflow is completed. This is what people think of when they visualize a flowchart. Alternatively, a workflow may wait for the next stimulus to cause a transition from one state to another.

An example of a flowchart-like, or sequential, workflow, might be a set of approvals, beginning with one manager and moving up the chain of command. Regardless of what is being approved, the workflow transitions through a set of actions waiting intermittently for new input. The flow is largely linear. Workflows don't go back from the "VP approval" state to the "manager approval" state. They simply progress through the process from one approval to the next.

Alternatively, you might have a process such as a contract negotiation which alternates between states where both parties may: counter offer, quit negotiating, or accept the last offer. The number of rounds in this sort of a workflow may be many or few. Ultimately, however, the stimulus (event) indicates the state that the item should next enter. These types of workflows are called queue-based or state machine workflows.

Both of these types of workflows—each of these views of how workflows work—is something that SharePoint supports through the use of the Windows Workflow Foundation. And Visual Studio is the most powerful environment for creating workflows in SharePoint; it's a fitting place to start.

Workflow Foundation
SharePoint's workflow capabilities are based on the Workflow Foundation, which is a part of .NET 3.0. Microsoft has a whole site dedicated to the Workflow Foundation, what it does, and how it works at. The Workflow Foundation is designed to make it easier for developers to integrate workflow into their applications in a consistent way.

Workflow Foundation (WF) supports both sequential (flowchart-like) and state machine (queue-based) workflows. This provides a great deal of flexibility in terms of how you define the workflow you're trying to automate.

Also included with Workflow Foundation is a set of activities. Within workflow these are the components—or shapes—in the flow chart or in the state machine workflow. Each activity performs a different function including looping, branching, and waiting on external events. This means that SharePoint needs only to add the additional activities that are specific to SharePoint features.

Why Visual Studio?
One might ask why use Visual Studio when you could just as easily—or perhaps more easily—use SharePoint Designer? The short answer is reusability. SharePoint Designer workflows, in addition to being more limited, are always associated with just one list. Although you can template that list and get copies of the workflow, fundamentally the workflows are not reusable. Visual Studio workflows can be reused without limitation.

Another valid question is "What about InfoPath?" InfoPath can be a part of the workflow solution—for those with Microsoft Office Sharepoint Server (MOSS) Enterprise, which is out of reach for many developers. However, the techniques you'll learn here are applicable to workflows that include InfoPath as well.