Skip to main content

State machines are a wonderful thing to easily control, manage and administrate long running business processes. For those of you who don't know what state machines are and why you should use them, I have put together a post on my personal blog which you can access here.

 

The purpose of this post is not to reiterate any content from my blog but to provide you with a template that I regularly use. Hopefully it provides a common standard for everyone and you agree with the approach taken.

 

Prerequisites

The following items will be required to make this template work:

  • A status column on the list/library to track the process stage as part of each item
  • The sub-processes should exist on the corresponding library or list.
  • A standard error handling process. This could be implemented as a UDA (User Defined Action)

 

What's the structure of the template?

There is three main parts to the template:

  1. Initiation: This part of the state machine checks the current status of the process, based on the item's status column. It then changes to the correct state of the process. Very helpful in cases where you have to restart a workflow at a certain stage.
  2. State 1-3: They essentially are the various stages in your process and are only place holders that can be adjusted, added to, remove, based on your process' requirements. As part of the template, each state has actions to set the status of the process and then start a sub-process.
    NOTE: there is no Change State actions in the State 1-3 branches of the state machine. Remember do put those in, according to your process flow. Otherwise you might end up running around in circles when testing your state machine and not going anywhere.
  3. Error Handling: The action set is a place holder for you to incorporate any error handling you might have to put in place. That way you can gracefully stop workflows and get someone to look at the issue, rather than just having it fail. There are numerous actions (especially integration actions) that allow you to capture errors. Following the workflow template, the process will start at the correct state when restarted, rather than from the very beginning.

 

State_Machine_Template.png

 

Hope this helps some of you and happy for any feedback you might have.

Great input Rob. Similar to your thoughts I didn't put them in as people might forget that they are actually there. A state will always be executed as a whole. Meaning that, if there is one Change State action further up in the process flow and then the one from the template, the last one will be used to change the state. So users will always have to remember to delete or amend the the last Change State action. I have however updated the post so people are aware. Thanks again.

Hello Patrick,

I have a little problem when using state machine. The workflow is taking about 5 minutes to perform to exchange state after passing through the state exchange component.

Any idea?

Thanks.

Hi Vinicius,

this is due to the timer job. I assume your environment has safe looping turned on which prevents workflows from going viral and lowering performance of your system. It is best practice to keep this turned on for production environments. However if you turn this setting off (in Central Administration) you should not experience any major delays. Please use it with care and like I said, preferably do NOT turn it off in a production environment.

Cheers,

Pat

Great example. I have a state machine workflow but I didn't put an error handling state in it. Excellent idea.

One thing to note as well ‌ – safe looping is applied to a workflow as it's being published. So you can technically disable safe looping, re-publish your workflow, and turn safe-looping back on to shield other workflows from the risk of infinite loops.

Just wanted to give you a heads up!

This is a great idea & one that was recommended to me from our SP guru.

I have added the Switch action to my workflow. When an error occurs, should I end the workflow & manually restart? or is there something else I should do to get it going again?

Shelley - The answer to this depends on the types of errors that you are anticipating.  If its truly an unexpected fatal error, then you may wish to send a notification, log some data and end the workflow.  If its an error that you can somehow anticipate then you could have logic that changes the workflow state and allows a user to take corrective action and then resume the workflow.

Outstanding article! I am implementing this on a workflow now, as we specifically need to terminate some of our workflows and restart them. Without the "Inititation" stage and error handling, we were left with a mess on our hands.

thanks Ray!

The article you mentioned on your personal blog doesn't seem to be there any longer: 

http://projectpoint.at/?p=1029 

Do you have a current link for that? I'm brand new to Nintex and trying to get up-to-speed.

Thanks!

 Jay

Thanks for highlighting that. I have amended the link and it now points to the correct page.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings