The Problem SolverWIndows Workflow Foundation
HomeShow ChangesEditPrintRecent ChangesSubscriptionsLost and FoundFind ReferencesRename



26-10-2006 16:23:26

List all versions

Designing Your Workflows

So you are going to add WF to your application, great but now you are faced with some decisions like:

  • Use state versus sequential workflows.
  • How much to put in a single workflow.
  • Where to leave all the information used by the workflow.

See SequentialVersusStateWorkflows for the details. Next time I will write about where to leave all the information/data required by the workflow.

So the next question is how much to put in a single workflow. This is basically a question of creating bit catch all workflows versus smaller granular workflows.

My take on this is to create uses cases and turn each use case into a workflow. So let’s look at an example. A customer goes to a online shop, picks a few items, orders them and ask form them to be shipped. This is the basic use case but we can think of a number of additional use cases that may apply. For example:

  • The customer might prefer to pick the goods up in person instead of having them shipped.
  • The customer returns some of the goods as defective.
  • The customer returns some of the goods as unwanted. In the Netherlands this could easily happen because a consumer is permitted by law to return any item within 7 days of the purchase in which case he or she should get a complete refund.
  • A customer might not pay the bill and legal action should be started.
  • Etc…

Now all of these actions are valid variations of the basic sale but would it be smart to design them all into the same workflow? No certainly not! The workflow would become excessively large and complex with lots of actions that never execute during normal operations.

So I suggest you create a basic workflow consisting of a normal sales action. This consists of:

  1. Pick items.
  2. Choose delivery method.
  3. Choose a payment method.
  4. Spawn a new delivery workflow depending on the delivery method.
  5. Spawn a new payment workflow depending on the payment method.
  6. Wait for the delivery workflow to notify the sales workflow that the delivery is made or canceled.
  7. Wait for the payment workflow to notify the sales workflow that the payment is finished.

Now the payment and delivery are separated out of the main workflow. This way it becomes easier to support alternatives or reuse them in other places. For example if the customer returns a defective item we will have to ship him a new one. Shipping is no different but the whole process of handling defects is vastly different from selling the original item.

An alternative to spawning new workflows would be to modify the workflow at runtime adding the required steps. The main benefit would be that everything stays nice and contained in a single workflow making it easier to track but the drawback is that part of the workflow is designed in code removing the a major benefit of WF in that a picture is worth a thousand words.


Model your workflows after the real processes in your organization. If one process activates another take a good look if it is really part of the first process of more the result of it. Often it will turn out to be just a new resultant process that really should be a different depended workflow.

Wiki Usage

This wiki site is supposed to be a shared resource. As a shared resource everyone is encouraged to add new content or modify existing content!

Enjoy the WF wiki.

Recent Topics