Introduction
I ran into a real challenge in creating my first state machine workflow for MOSS, so I thought I’d share a quick demo (OK, not that quick: it is a workflow, after all) and hopefully save you some time.

This will actually be a short series of posts covering the following topics:

1. Concepts and planning (this post)
2. Creating InfoPath forms
3. Developing the workflow
4. Deploying the workflow

Before you get started, you’ll need to make sure you’ve downloaded and installed the latest Office Server SDK (which comes with the Visual Studio workflow templates for SharePoint).

If you haven’t done any MOSS workflows yet, I’d check out Nick Swan’s blog post on a sequential workflow walkthrough -- I think that’s a good place to get introduced (and a good blog to add to your regular reading) -- then come back here and try your hand at a state machine.

Business Case
State machine workflows are good at automating processes that change between different states (or statuses) throughout the lifetime of the workflow. They have a defined beginning and end state, but the behavior in between those two points can vary based on inputs.

In this example, I’ll show a quick state machine representing a proposal creation process.
Let’s say Acme Widgets uses a proposal process to quote prices and sell its goods.

1. Roger, the salesperson, prepares a proposal, which must then be reviewed by the sales manager, Sheila. 
2. Sheila may either approve the proposal to submit to the customer, or she can kick it back to Roger for modifications. 
3. If Roger has to modify it, he does so, and then sends it back to Sheila for approval. 
4. Once approved, Roger submits the proposal to the customer and awaits the outcome.
5. The customer can do one of three things:
• Accept the proposal
• Reject the proposal
• Request modifications to the proposal

A graphical representation of the process looks something like this (click the image for a larger version):

The colored bands in the diagram represent the “state” of the workflow at a given point in time. This concept will be important when we actually design the workflow.

Side note: If you don’t do it already, I’d highly recommend doing a conceptual flow chart (similar to the one above) for your workflows. It doesn’t take long and offers clarity for you throughout the development process.

Note that the ability to go “backward” in the workflow is one of the factors that will determine whether you choose to implement a state machine workflow instead of a sequential one.

Planning
Based on the flow chart that I created, I can easily see what InfoPath forms I’m going to need to create for the various steps in the process.

1. Association Form. Ok, this isn’t represented in the flow chart, but I know I’ll need to create one to set any association-specific information for my workflow.
2. Initiation Form. This will be the one that is filled out when the workflow is first initialized.
3. Review Form. This will be the form used by the proposal reviewer. It needs to have the option to approve the proposal or to send it back to the creator for modifications. In either case, the reviewer should have the option to add comments that will be written to the workflow history list.
4. Modification Form. This form will be used by the salesperson to comment about any changes made to the proposal when re-submitting it for review. I can probably use the same InfoPath form as the initiation form here.
5. Pending Customer Form. This form will be used to specify the outcome of the submission of the proposal to the customer. The possible options here are to send the proposal back for modifications, mark that the customer rejected the proposal, or (hopefully!) mark that the customer accepted the proposal.

At this point we’re ready to dive in. In my next post, I’ll walk through the steps of creating the InfoPath forms.