The Problem SolverWIndows Workflow Foundation
HomeShow ChangesEditPrintRecent ChangesSubscriptionsLost and FoundFind ReferencesRename



1-2-2007 20:41:0317-10-2006 15:00:03

List all versions

Sequential Versus State Workflows

Windows Workflow Foundation offers two basic types for workflow, the sequential workflow and the state workflow. So when you start building a new workflow which is right one for you? Well it depends! You knew I was going to say that didn't you?

The StateWorkflow is the more fluid of the two. Basically the workflow is in a given state and waiting for events to move it into another state. This new target state can be every other state in the workflow. Normally this happens because an event is raised and the current state, or one of its parents knows how to handle the event and does so to trigger a state change. The workflow itself actually has another way, the SetStateQueue queue with a SetStateEventArgs argument to indicate the target state, which can be used to activate any other state, even if there is no event that has the new state as target. This makes state workflows very much like real live. After all how often are we not faced with issues that are not supposed to happen in the normal flow of things?

The SequentialWorkflow on the other hand is much more rigid. Sure it can contain loops and branches with conditions but basically the path through the workflow is deterministic. So this is much more in line with automated processes or very rigid protocols that need to be applied. This doesn't mean that things cannot go wrong or if that happens we cannot cater for it but there is a clear distinction between the normal execution path and any exceptional deviations.

So what to choose?

Well the above basically gave it away already. If you have a rigid protocol, say for example you submit an expense report, you manager has to approve it, then if the amount is larger that a certain predetermined amount a senior manager has to approve it too and finally ou get the result (and with any luck some money) you are probably best of with a sequential workflow.

If on the other hand the same process is modeled more in terms of you submit it, your manager reviews it and might ask for clarification on some items. When done it goes to his supervisor, who in turn can send it back to you for more clarifications etc. In a case like this a state workflow seems more appropriate as the state of the expense report moves all over the place from submitted, to waiting for approval to waiting for clarification and back to waiting for approval.


So the way I read it, the above article doesn't say 'use sequential here and state-based here', but 'either will do'. If you've got other arguments as to why one should be used in preference to the other I'd like to hear them...


For example. In a recent project I created a workflow with two points the work needed to be checked and if the check failed part of the work needed to be redone. Because the whole process was very rigid and government regulated, my first choice was a sequential workflow. But because the two check, where the checked check failing would end up just before the first check, required a number of extra loops the workflow became hard to create but easy to visualize. When I redid it as a state workflow it was much easier to implement because there was no need for a looping construct. But then the drawback was that is was harder to see what was going on in the workflow itself

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