Nintex Workflow - How to potentially avoid workflow throttling using logic based state machines

Nintex Employee
Nintex Employee
0 0 402

Hello, My name is Jake Dennison and I am a senior solutions engineer here at Nintex.


One of the most regular workflow designs I see with all lines of business is the use of multiple approvals are repeating the same actions but with only minor differences each time.


Currently it seems the preferred method to solve such workflows will be to use State machines to build branches for each step, Although this works and is fairly straight forward to pull off, I believe it has some minor drawbacks in some situations and in some extreme cases in the cloud, may cause bad workflow performance and throttling.


The kind of state machine I am talking about may look a little like the below but can be much bigger.

workflow example.png














I regularly see state machines where at first they were made to only suit 3-4 approvals which is perfectly fine and exactly how you should use the state machine, however over time processes grow, more and more is added in and eventually you may find instead of having 4 branches, you now have 2 state machines each with 27 branches yes this is a real world example. Although the said workflow worked, It was slow to start and would regularly fail and error, due to its size and complexity it became difficult to maintain and hard to troubleshoot whenever there was an issue. 


As a solution to this I came up with an externally managed state machine that uses data from the SharePoint to complete its logic, It works a little something like this, This is an early and basic example of what can be achieved, with real-world testing and improvements I am sure it can be more. 


  1. Start out by building your Logic Matrix List, this is where you will store the information needed by your workflow to complete each branch, here we will be converting branches into list items.


  2. In your workflow you will need to add a query list action configured to return the IDs of all the list items in your Logic Matrix List
  3.  To keep track and make the workflow run smoother we will need to reduce the 'result count' variable by 1, this is so we can keep the result count in sync with the index which starts at 0 and not 1.
    To do this you will need to add a 'Do Calculation' action.

  4. Now we can add a state machine with 4 branches (Logic State, Task State, Rejection State, Approved State)
  5. In the Logic state branch we want to use a get item from collection to get the ID of the first approval item, in this action we created a new variable for the index, you need to ensure the default value of the index is 0, you can do this by ticking the 'initiation box' and then clicking on the settings icon, here you can set the default value to 0. then untick the 'initiation box'. We are also storing the current runs ID into ConfigID variable.
  6. To prepare for our next run we should increase the index by 1 as soon as the get item from collection is completed, Use a 'Do Calculation' action to achieve this.

  7. Finally complete the branch by adding the change state action to move to the Task Stage, it should look like this.


  8. Now we are in the Task Stage things get a little more complex and interesting.
    If you have unique actions for the current run (in our example we have 3 different actions in each) you can handle this by adding those actions into run if statements, And in combination with the additional fields in the logic matrix you can choose to run or not run an actions based on the current item.

  9. We also add a single task action configured as below, this checks if the current run matches the index, if so then it knows this is the final approval.

  10. Finally the whole state machine should look like this, with the success and rejection branches configured how you wish.

With some simple changes you can add some more complex actions or abilities such as red-lining and workflow re-start ability, Perhaps I will show those in a future post or if you're interested please feel free to reach out to me.


As a result now we have a workflow that completes all of the approvals we had before in exactly the same way however we have the following benefits.


  • To add more approvals we just add a new list item to the logic matrix list
  • To change an approval for even workflows that are currently running we can change the item in the logic matrix
  • We can use this to standardise the email message templates and task titles
  • We no longer need to modify the workflow to maintain or change any approvers, only if we we need to change setting.
  • We could have greatly reduced the number of actions used from possibly hundreds to in the 20s, it is also unlikely to grow no matter how many more approvals I add.
  • The workflow is less likely to throttle as it is much smaller and it no longer needs to reserve the timer services for dozens of approvals, only 1. 
  • In each of the logic runs you can store the current run in the list item, this would allow you to restart the workflow where it left off if needed.