Vadim Tabakman

For those that haven't seen this, I wrote a post about a Smart Workflow. It was a workflow that utilized a State Machine and various states, to keep track of what it had done last.  Then, if you happen to terminate the workflow and restart it, it would figure out roughly where it was, and then jump to the appropriate state so it wouldn't have to redo most of the stuff it had already done.

Today, I encountered a question about an already running workflow which they needed to update the design, terminate and restart it.  But they didn't want it to start from the beginning.

I came up with the following idea.


I have a number of workflow that have been running and are waiting on a Request Approval.  They have done a lot of work already, and for some business need, I need to update the workflow design, stop and start each of the workflow instances so it uses the latest business logic.

The problem is, I don't want it to redo all the stuff it has already done.


When you terminate a workflow, it gets a particular status.  In this case "Cancelled".

You can make a call to the Nintex Workflow web service, specifically, the GetWorkflowHistoryForListItem web method.  The method takes parameters like Item ID, List Name, Workflow Name, and the State of the workflow.  So we can ask for the Cancelled state.  In essence, this will tell us if we have had an instance of this workflow already run on this item and it has been terminated.

If there is workflow history, you will get a bunch of XML back.  If there isn't, you'll get an empty text string back.

Then you simply need to jump to the appropriate part of the workflow.  How do you do this?  Use the state machine.


The scenario is, we have a simple item with a number and date field.  The workflow runs and updates these (add 2 to the number field and 7 days to the date) and then send an approval request.

After the first run of the workflow, it updates the NextID and DateNextMeeting:

If you were to rerun this workflow, it would update the NextID and DateNextMeeting again, which is not something we want.

The workflow looks fairly simple:

When this workflow runs, it updates the fields quite quickly and then sits and waits on the Request Approval.

The business has asked that I modify the approval request and do something special or even add some more business logic after the approval.  But they want this to happen to all running workflows also.

The solution I came up with, was to use something similar to my Smart Workflow idea, and that is utilize the State Machine.

Initial State - checks if a previous instance of the workflow ran and was cancelled

Beginning State - is the start of the workflow if it has never run before

Middle State - contains the Approval Request action

Firstly, we run the web service call:

Then we check the result and depending on whether we got data back or not, we jump to the appropriate state:

So we've gone from a fairly simple workflow of 5 actions, to a workflow of 13.  But atleast we have somewhat of a solution.


When you terminate the workflow, the item then looks like this:

You can see now that we run the smarter workflow, it has kept the NextID and DateNextMeeting values as they were, since they've already been updated.

The graphical view of the workflow can be seen here:

You can see that it has gone to the Initial state, figured out that a previous instance ran, and so we don't need to go to the Beginning, and instead, it jumped straight to the Middle state which does the Request Approval.

Suggestions for Improvements

This is a solution, but it's really not perfect.  Since most business workflows are more complicated than this. 

Something I would leave for the reader, is that the amount of data that comes back from the workflow history (web service call) is quite large.  It may be possible to interogate that information and cater for more situations in your workflow.  It would definitely make you workflow larger though.


Posted by Vadim Tabakman Friday, June 8, 2012 7:25:00 AM Categories: Calculate a Date Call Web Service Change State Math Calculations Nintex Nintex Workflow Request Approval State Machine
Copyright Vadim Tabakman
Rate this Content 0 Votes


Saturday, June 9, 2012 10:16:47 AM
K Rock

re: Nintex Workflow - The Almost Smart Workflow

Hey Vadim,

This the type of out of the box thinking that I need to put into many approval workflows.  The desaster thing is that the workflow errors unexpectly at the end and then you restart it and goes back to the approvers.

This would fix this issue!

Saturday, June 9, 2012 12:51:20 PM

re: Nintex Workflow - The Almost Smart Workflow

Hi Vadim,

Thanks for this detailed post! It's not the perfect solution for us, but at least we don't lose migrated workflows completely.

Saturday, June 9, 2012 5:38:48 PM

re: Nintex Workflow - The Almost Smart Workflow

Agreed dbaranyi.  It's not ideal.  Nintex Workflow "usually" stores which actions in the workflows have started and completed.  Ideally, we could figure which action was last run and not completed, and when the workflow is restarted, it figures out from that which action to jump to.  Unfortunately, there's no way to jump to a specific action in a workflow.  I'm not even sure this is possible in WWF.

Wednesday, July 11, 2012 7:01:04 AM

re: Nintex Workflow - The Almost Smart Workflow

What I do is create another column on the item called 'gate' then the first item on the workflow is to set the machine state based on the gate value, at the end of certain sections, I then set the current item to the correct gate.  That way if it needs to restart, or is started on every save, it can figure out where it is.... To keep users from mucking it up, I remove the gate from the infopath form they use every day...

Wednesday, July 11, 2012 7:02:53 AM

re: Nintex Workflow - The Almost Smart Workflow

Haha, I just saw the other post... maybe I should start at the front and work my way back.. lol

Monday, August 27, 2012 8:53:50 PM

re: Nintex Workflow - The Almost Smart Workflow

Since the in process variables and other data items get lost when restarting workflows, we end up creating a second list (with a primary key of the workflow itemid) and then create a user defined action for updating/reading this list easily. We keep states, variables, etc, in this other list which the users don't have any access to.. The smarter users are starting to figure out ways to edit list items and changing things to "Approved" or kill the workflow and restart manually after setting the status to the desired output. Removing the fields from views and forms is easy to do, but not secure.

Tuesday, August 28, 2012 7:25:19 AM

re: Nintex Workflow - The Almost Smart Workflow

Hi HM,

that sounds like a great solution.

Monday, February 25, 2013 4:38:07 AM

re: Nintex Workflow - The Almost Smart Workflow

Since we use a lot of InfoPath forms, we save the state in a hidden repeating table in the InfoPath form. Should the workflow be cancelled and restarted, the state variables are read and the workflow commense where it was interrupted. In some forms we even have a audit trail in a repeating table to know who already did approve/reject the form.

Monday, February 25, 2013 7:03:12 AM

re: Nintex Workflow - The Almost Smart Workflow

Hi Bennie,

I like that solution!! Thanks for sharing it.



Wednesday, March 20, 2013 3:49:57 AM

re: Nintex Workflow - The Almost Smart Workflow

Hi Vadim,

does this Workflow history return values of the variables, assigned during previous instance? 

For example, my workflow keeps last approval stage in variable named LastState . If workflow has been cancelled, does this method is able to "extract" value of the LastState in next run?

Thank you for explanation!

Friday, March 22, 2013 7:23:41 AM

re: Nintex Workflow - The Almost Smart Workflow

Hi Yevgeny,

I don't believe it does, unless you log the variable values to the history.

Nintex doens't automatically log the variable values into the workflow history.



Friday, January 31, 2014 9:28:18 AM

re: Nintex Workflow - The Almost Smart Workflow


i have a requirement in which there are n number of approvers.. I am using State Machine for the Approval process.. Now if in the process if say the 4th approver rejects, i need to start the workflow again from the 4th approver .. I am using an infopath form and have a button which can Resume this action 

How can I go about doing this

Wednesday, July 2, 2014 12:53:54 PM
Ohad Leichter

re: Nintex Workflow - The Almost Smart Workflow

First off - your blog is the best Nintex resource out there by far, and always my first stop. Thanks for being there.

Regarding having to stop/restart workflows, I ended up taking a different approach for some very long running, multi-task workflows. I added a "Step" field to the list using the workflow, and each time a discrete task was completed, I advanced that step by one place (so it I completed task 5 out of 12, the Step value would be 5.

Then within the workflow itself, I placed each of those tasks and associated elements into a "Run If" action set, with the condition being that the current Step in the list be < the "Run If" trigger. (So to get into the set to do task 5, the Step must equal <5).

By stringing these tasks together, whatever point I have to stop a workflow, I know it will restart where it left off. This method also makes it easy for anyone to view the workflow diagram to see where the original ended and the restart picked up. This has saved us countless hours of having to manually reset things for a restart.

You must sign in to this site to post comments.
Already Registered?
Sign In
Not Yet Registered?


  • Entries (290)
  • Comments (1777)