When to Use State Machines

Windows Workflow Foundation includes two very distinct types of workflows (state machine and sequential, which were introduced earlier in this book), and there are situations in which one type may work better than the other. However, sometimes this is not obvious, so it may come down to which type seems right given the problem at hand. However, there are several criteria that can give you a good idea of the workflow type that is right for your project.

One thing that can tip you off that you should use a state-machine workflow rather than the sequential variety is when the workflow has a large amount of human interaction. That is not to say that sequential workflows should not be used when humans are involved in the process, but workflows laden with human interaction are generally easier to model as a state machine. This is because whenever a person performs an action, a process progresses to another step; and in reality the word progresses is not completely accurate - it implies a forward movement. State machines are able to jump all over the place, depending on what the developer defines. Consider a state-machine workflow representing an order processing system. An active workflow instance could not jump from an Order On Hold state to a Waiting For Order state - that just wouldn’t make sense. However, there are no restrictions on how many states another state can progress to.

State-machine workflows are also a natural fit when events that fire outside the bounds of the workflow are plentiful. This generally implies that the workflow is made up of a discrete set of steps, or states. State machines do well in these instances because each discrete step in a state machine is progressed to because of an event that is fired. Consider the order processing workflow again. There might be states called Pending Approval, Approved, and Completed. Each of these three example states is entered because the corresponding event occurred. Perhaps the workflow enters the Pending Approval state when the customer has finished entering an order for a large amount. The Approved state might be entered when an order specialist investigates the pending order and decides everything is good enough to ship. Finally, the Completed state might be entered when the customer’s credit is verified.

If a process seems to have several instances when certain actions can occur at any point in the workflow, a state machine might be a good candidate. This is because as previously mentioned, states in a state machine can be entered in any order as long as you have defined the workflow this way. An order should probably be able to enter the On Hold or Canceled state at any time. If something goes wrong with a customer’s order at any point in the process, a customer service representative can place the order on hold until the issue is resolved. The same applies if the order needs to be canceled.

Again, although there is no magical formula that tells you when to use a state-machine workflow instead of a sequential workflow, a lot of the time it comes down to what feels right. Because the sequential style is the most common workflow because it is the archetypal process modeling mode, developers will probably tend to choose a sequential workflow when a state machine could get the job done in a more efficient manner. If you are developing a sequential workflow and it starts to become difficult to allot for every execution path, or the process you are modeling just does not feel natural, it’s time to consider a state machine.