State machines are an approach to workflow design that allows a lot more flexibility, a lot more readability, and a lot less chaos to almost any process model. In a very real sense, almost all workflows would benefit from being redesigned as state machines, but certain use cases fit this design model particularly well. This session will explain what state machines are, why to use them, how to create them in Visual Studio and other products, and how to redesign a number of workflow models as state machines instead.

1. State Machine Workflows: Esoteric
Techniques or Something Everyone Should Be
Using?

2. Setting Expectations
• This session is about workflow design
– I want to advocate a way of thinking
– Plenty of resources exist for coding; this isn’t one of them
• If you already understand state machines, and you already
like them, this session might not be for you
• I will indeed use Nintex Workflow for some demos
– I know it well and can illustrate a concept quickly with it
– But this is not a session pitching Nintex Workflow
– Other products can do state machines, too

3. Consider A Press Release
•
•
•
•
Author
Management
Legal department
Publisher

4. You May Think Like This

5. Or Perhaps This

6. What About
• Getting professional editorial help?
• Other outcomes?
– e.g., Legal wants to clarify a point with
Management

7. How About This?
Authoring
Manager
Approval
Legal
Review
Publishin
g

8. How About This?
Authoring
Manager
Review
Legal
Review
Publishin
g
(re)Submit?
Choice
Choice
Deploy to Public
SharePoint Site
No
End
Yes
Mgr
Rev
Request
changes
Auth
Forward
to Legal
Mgr
Apr
Request
changes
Auth
Request
clarification
Approve
Pub
Mgr
Apr
End

9. Or Even This?
Authoring
Manager
Review
PR
Polishing
Legal
Review
Publishin
g
(re)Submit?
Choice
Choice
Choice
Deploy to Public
SharePoint Site
No
End
Yes
Mgr
Rev
Request
changes
Auth
Approve
PR
Draft Changes
Approve
Request
changes
Request
clarification
Auth
Auth
Approve
Request
clarification
Leg
Pub
Mgr
Apr
PR
End

10. State Machines
• States
• Events
• Transitions
State
Switched On
Event
Transition
Button
Click
Transition
Button
Event
Click
Switched Off
State

11. •
State Machines vs. Sequential
Workflow
Sequential Workflow
–
–
–
–
–
•
Predictable
Wait, then march forward
Workflow is in control of the process
Most decisions happen within the workflow
Workflow’s job is to direct
State machine workflow
–
–
–
–
–
Event driven
No concept of “waiting”; workflow is in one state until it isn’t
Actions are in control of the process
Most decisions happen outside of the workflow
Workflow’s job is to govern

12. Bug Tracking Example
How you think it works
• Tester opens bug
• Developer fixes bug
• Tester approves fix

13. Bug Tracking Example
What really happens
• A tester opens a bug, and assigns it to Bill.
• Bill says, “no not me, this is Clive’s”, and reassigns the bug to him.
• Or Bill says, “this tester is not in this case quite correct” (or words
to that effect), and rejects the bug as nonsense.
• Or Bill asks the tester for clarifying information.
• Or even, if he’s in a good mood, Bill fixes it and hands it back to the
tester.
– Or, if the original tester is out, another tester.
• Or the tester withdraws an erroneous bug (surely not)
• And so on.

14. Bug Tracking Example: Sequential
Tester T creates instance of bug workflow
T adds bug details
T assigns to developer D
LabelB:
Switch
D assigns to developer E:
Goto LabelB
D rejects bug to T:
Switch
T accepts rejection:
Exit
T updates bug and assigns to developer F:
Goto LabelB
End Switch
D requests info from T:
T submits info
Goto LabelB
D submits solution to T:
GoTo LabelB
T withdraws bug:
Exit
End Switch

15. Bug Tracking Example: State Machine
•
•
•
•
•
•
State: Initial
– Action: T adds bug details
– Action: T assigns to developer D; new state = Fixing
State: Fixing
– Action: D assigns to developer E
– Action: D rejects bug to T; new state = Rejected
– Action: D requests info; new state = Pending Info
– Action: D submits solution; new state = Pending Approval
– Action: T withdraws bug; new state = Closed
State: Rejected
– Action: T accepts rejection; new state = Closed
– Action: T updates bug and assigns to developer F; new state = Fixing
State: Pending Info
– Action: T submits info; new state = Fixing
State: Pending Approval
– Action: T rejects solution; new state = Fixing
– Action: T accepts solution; new state = Closed
State: Closed

16. Even “Obvious” Sequential Processes
Can Be Secret State Machines
• Expense approval
– Usually, if any problem, reject and restart
• No way to track how long it takes to get an eventual outcome
– Model back-and-forth into the workflow
• Escalation
• Return for clarification
• Leave approval
– Allows negotiation to be factored in to the process

17. When Do You Use a State Machine?
• When you need
– Flexibility
• You can add new states with minimal impact
• You can modify steps within a state without fear of wide impact
– Visibility
• The more complex, the harder sequential workflows are to read
• Harder to visualize graphically, but very easy to read a log
– Control
• Counterintuitive
• You can easily define how to skip steps
• You can more easily manually induce a revert-to-state, skip-to-state
• Actually, almost always

18. Why State Machines are Useful
• We want workflows to follow a predictable path
– We find that real-world demands get in the way
• Without state machines, you’ll wind up with:
–
–
–
–
A lot of If-Then-Else conditions
A lot of looping
Lots and lots of arrows to the point of “Spaghetti”
Graphical “goto” statements
• Most workflows actually wait for people to do something
– That’s a “decision outside of the workflow” scenario
• The current state is useful for status reporting

19. Sequential Activity Inside a State
• Inside of a state, sequential actions take place
–
–
–
–
–
Evaluate conditions
Transform data
Process transitions
Branch based on conditions
Assign tasks
• Technically, some of these a mini-state changes
• You can nest state machines inside of states

20. Sequential Flow Using State Machines
• Define the rules correctly
• State machine workflow will follow a
predictable path
• Until you need it not to 

21. Can Users Understand This?
• Don’t call it a “state machine”
• Call them “stages” instead of “states”
• Call it “moving back and forth” rather than
“transitions”
• Users love being able to handle exceptions
• Users love being able to change rules

22. Using State Machines for Exception
Handling
• Add “Error Encountered” state
• Have workflow actions change state upon exception
• Have “Error Encountered” state:
– Undo earlier work
– Create compensating actions if necessary
– Report error to process owner

23. Using State Machines to Restart a
Workflow Where It Last Left Off
• Add a field to a list item; leave it out of most views
– “Internal Workflow State”
• Workflow begins in “Evaulate Initial State” state
– Checks InternalWorkflowState variable
– Transitions to correct state accordingly

24. Can You Loop? You Can Simulate a
State Machine
• You will need:
– Variable
– Loop
– Switch
• Steps:
– Set variable to initial state immediately before loop
– Put a switch inside a loop
• Switch evaluates variable and branches accordingly
– When you need to change state, change the value of that variable and
wait for looping to occur
– Make sure at least one of the states
causes the loop to end

25. You Can Even Do This In SharePoint Designer
(Sort of)
• Warning – this is for entertainment purposes only
• One field to store current state
• One startup workflow, plus one workflow for each state
– Last step of each workflow sets a field value
– All state workflows started by modification to item
(except for the workflow that caused the change to take place, of course)
– Each workflow first checks state field, exits if not target state
• This isn’t practical, though
– It effectively starts all state workflows (other than the current one) with
every change
– Plays havoc with the audit trail

26. Windows Workflow Foundation 4.0
• Microsoft removed state machines from WF 4.0
• Introduced a Flowchart workflow type instead
– Still consisted of states
– Graphical paths between states
– Worked for many use cases
• Backlash ensued!
• Microsoft later introduced a State Machine activity
– Posted to CodePlex
– http://wf.codeplex.com/releases/view/43586

27. Conclusion
• State machines sound esoteric – they’re not
• State machines have genuine practical benefits
• This is a way of designing, not coding
– State machines can behave sequentially if need be
– Sequential workflows can behave like state machines if need be
• Many products can do this
• A lot of content exists to help

28. Questions & Discussion

29. References
•
•
•
•
•
•
•
http://msdn.microsoft.com/en-us/library/gg508985.aspx
http://msdn.microsoft.com/en-us/library/dd692929.aspx
http://odetocode.com/code/460.aspx
http://srisharepointdevelopment.blogspot.com/2010/06/state-machine-vssequential-workflow.html
http://vtonms.blogspot.com/2010/01/nintex-workflow-smart-restart-workflow.html
http://blogs.msdn.com/b/davegreen/archive/2005/10/20/483309.aspx
http://blogs.msdn.com/b/pravin_indurkar/archive/2005/09/25/473826.aspx