I've been thinking about some fundamental differences between WF and a few 3rd party workflow tools (Metastorm, Bluespring Software and others). In WF, describing a workflow process is conceptually similar to designing a Windows form.  Utilizing the Visual Studio design time capabilities of activity classes we can configure our model. Code-behind implements the configuration and is eventually compiled into a "runnable" workflow. The 3rd party tools I've worked with provide a more explicit seperation of the process description metadata and the workflow engine runtime. Generally a process description tool allows the process to be modelled and published to a persistant store. At runtime, the workflow engine utilizes this metadata to execute an instance of a workflow.

Initially the WF approach seemed flawed. I instictively felt it was Microsoft's bias that everything should be source code and modelled in Visual Studio. But the more I've thought about it the more I like it. The conceptual seperation of a process model (imperative description) from the knowledge of how to execute it is maintained. And because XAML markup can fully describe a process model and be compiled at runtime to an executable form we still have the capability of describing a workflow outside of Visual Studio without code-behind. A significant strength of the approach is the capability to utilize inheritance to begin to develop more specialized activity classes that fit a particular subject area. These classes can provide specialized design time features that make them easier to configure. For example, we might develop a general activity to send an email. This activity provides many parameters to allow for comprehensive email functionality. Now for a specific kind of workflow process, for example a standard "approval" process, we might sub-class this activity to create a specialized email activity that simplifies the design time configuration for a simple approval notification. This is difficult in tools where you have an immutable workflow engine that accesses a pre-defined respresentation of metadata. The functionality of the engine and the process description semantics are designed to be general and capable of supporting whatever a customer might dream up. The least-common-denominator approach makes designing workflows difficult.