Developing workflows in WSS 3.0 inside Visual Studio

One of the big features in WSS 3.0 includes their support for workflows (they have a new dependency on Windows Workflow Foundation in the .NET 3.0 framework).  This should help make a lot of the scenarios that people were coding in WSS 2.0 a lot simpler and easier to both develop and manage.

If you're new to Windows Workflow Foundation like I am, you can read this excellent MSDN white paper.

To summarize, here is an application of these terms in the workflow life cycle:

  1. Developer develops a workflow template.
  2. Server box administrator deploys the template to a site collection.
  3. List administrator associates a workflow template with a list or content type on that site collection to create a new association.
  4. User starts an instance of a workflow association on an item (or workflow instance starts automatically on event).
  5. Workflow executes, perhaps creating some tasks and history items on the Tasks and Workflow History lists specified in the association.
  6. Workflow owner (the person who started the workflow) or list administrator can talk to a running workflow at any time by modifying it with a modification.


It’s not critical understand the low level details of how workflows operate internally to develop workflows, but there are a few the important high level concepts that will help:

  1. When running workflows reach a point in the code, a.k.a. schedule, where they need to wait for something to happen (such as a task edit), they are serialized (i.e. turned into binary) and dehydrated to the SharePoint database.This means that the workflow object is turned into a string and stored to the database. We can say that the workflow is asleep.
  2. Dehydrated workflows are no longer in memory.
  3. When the event the workflow is waiting for happens, the workflow is deserialized and wakes up, or rehydrates, then continues where it left off in the schedule.