Recently the topic of a state machine came up with Sean Docherty. I wanted to put thoughts to paper so that I can share my experience with the community and see what others view points are.

The Scenario

In this example I am creating a workflow for a software acquisitions process. Below is a high level view of the steps taken:

1. The user fills out a basic form requesting software

2. The planning team updates the form with the PRODUCT ID

     a. The workflow checks to see if it has been CANCELLED

3. A task is generated for the requester's supervisor to approve

     a. If approved, the planning team schedules an INSTALL date and completes the request

     b. If denied, the requester is notified with details on why

     c. If no action is taken with 24 hours, the request is automatically cancelled

For the sake of this post I am going to keep the form piece of it out and focus on the workflow that is driving the process.

The Workflow

The workflow is setup to trigger when a NEW item is submitted. Upon entry, the item enters the state machine in the NEW branch and waits for someone from the planning team to select a PRODUCT ID from the company catalog. We also check to see if the status is 'Cancelled' just in case someone cancels the request prior to requesting approval. The workflow then moves over to the PENDING branch. Here is where the task is generated and requests supervisor action. There is three possible outcomes:

     1. Approve - The supervisor approves the request and moves the workflow into the APPROVED state.

     2. Reject - The supervisor rejects the request and moves the workflow into the DENIED state.

     3. If no action is take within 24 hours, the task is escalated and automatically completed and moved into the CANCELLED state.

If the request is approved, the workflow waits for someone from the planning team to update the request with the date for the software install. At this point, the workflow finishes and the request has been completed. If denied, the requester is notified with details regarding why, and the workflow finishes. Lastly, if the request is cancelled due to inactivity, the requester is notified and provided explanation on why and what to do if wanting to re-submit. This is accomplished buy using the Escalation part of the Flexi Task action (see below).

Additional Thoughts

I try to use a State Machine in my workflows when an item has a life-cycle that is short and needs to be monitored. I look for short life-span so that I do not have workflows running for extended periods of time. Also, for this example, because we are updating the 'status' of the item with each new state, we can build a view within SharePoint that provides an up-to-date look at what is coming in, being worked on, and at what stage it is in. I am also attempting to leverage more of the 'Expected Duration' piece of the actions I use and monitor where things bottleneck or take almost no time. To do this, simply look in the Common section of the action and select a duration.

As always, there are many different ways that this could have been accomplished; you could use a switch action and evaluate the status each time or you could make the entire thing linear. I choose to use a state machine because it allows me to see what state an item is in at any moment and it provides me greater opportunity when I go back and automate more. For example, I would create a process that looks up the available products from the catalog and picks an open license or notify the planning team that a purchase is required (a whole new process). This step could easily be injected into the current workflow under the NEW state and not disrupt or require redesign.

Please, let me know what you think or what you have experienced regarding state machines!

Until next time!