State Machine by Example

  • 1 March 2016
  • 7 replies

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!

7 replies

Hello Jesse,

Thank you for this post! This article was awesome!

You have given me a whole new appreciation of the State Machine and its flexibility.

Very well done!

Sean Docherty


Let me know if you ever need help with anything else and I'd be happy to put something together so we can all learn!

Thanks for the article.

I have a question regarding ending the state machine with an End Workflow action. I saw some articles warning in doing so.

Currently I am also considering to use the End workflow action to end a State Machine.

The reason is I want a simple way to end the workflow when there is no item change within one state.

Would it make any difference if I put an End State machine action before the End Workflow action?

It would be nice if some could shed some general light onto the State machine behavior regarding the End Workflow action.



Hello Thomas,

I have a workflow for a PO Requisition system that has two State machines in it. Jesse McHargue​ was very helpful in providing some tips into the State Machine object when I was developing this workflow. If you haven't read it yet, you should read Jesse McHargue's​ article State Machine by Example

In the second State Machine I use the End Workflow object at various points in this workflow as you can see below.StateMachine.jpg

The End Workflow object works very well for me in the workflow that I have pictured above. To me it seems a bit redundant to have the End State Machine action and then have the End Workflow action right after it.

If all of your conditions, actions or whatever you are trying to achieve in the branch of your State Machine are meet and you have no reason to pass the information onto another branch of the State Machine, then I would add the End Workflow action into your State Machine. This is a nice clean way, as far as I am concerned to, end your State Machine action and your workflow.

Hope this helps Thomas.

Hi Sean,

thank you for your answer which is very helpful.

I also read Jesse McHargue's article State Machine by Example.

I was just a bit unsure when I found this article

Action state machine to change to next phase

where it says " not use End Workflow inside of your state machine".

If you use the End Workflow in your State machines without any problems it is probably safe for me too.



Hello Thomas Olbrich​ -

I use the End Workflow action in mine because there are no other actions that need to occur at that point. If you have other actions that need to occur, use the End State Machine action and drop out of the State Machine. I have not ran into any issues with this approach, but my workflow is only the state machine, there are no other actions before or after it; it is all self-contained.

This this helps!

It is a bit late but thank you Jesse for your comment.

It is helpful.