Best Practice Question – Tracking Multiple Item States

Discussion created by N M on Dec 10, 2018
Latest reply on Jan 8, 2019 by emha

This is a general best practice question for people who have been around the block a few times with Nintex Workflow for SharePoint (on prem, though I'm not entirely sure that it'll matter). 

The Basic scenario is this. 


I have a SharePoint List we'll call "Orders" that has a Nintex Form for the only Content Type (Order) available. The Order Form contains a Repeating Section of 'Line Items' which can be filled out by the user. Those Line Items, at some point further on in the process, will be converted to individual Items on another List (let's call it 'Line Items List') on a different Site


Each one of thoseLine Items have a workflow which runs on it and carries it through various States as people complete tasks and verify the integrity of said work. 


However, at a particular 'State', I would like to create a SINGLE task back on the Site containing the Orders List, so that the Order's creator can do a final verification of all the uploaded / modified data on those Line Items


This is a simple visual to kinda show what I'm on about: 


As you can see, I'm going from One to Many and then back to One. 


The problem is, is that I have not found a particularly good way of going from Many down to One. Tracking the changes of Multiple Items isn't something that is included out of the box (as far as I know) with the Nintex Start Conditions. If they were, I could easily say do something along the lines of "If all of the items with the related Order Number have Statues beyond X, then Run this workflow", but this is not the world that we live in. 


There are a few ways that I have fiddled around solving something like this, but not a single one of them is completely satisfactory. Thus far I have tried the following. 


  1. Once a Line Item reaches the stopping State, have it look around at the other Line Items to see if their statuses are at the same point or beyond, if and only if they are, execute the workflow ONLY on the item doing the checking.
    • This can fail if two (or more) tasks are completed too closely to one another, and they both see all of the other items as being in a state that would let them think that they should run the next step. 

  2. Once a Line Item reaches the stopping State, have it increment or modify a column BACK on the Order List Item which will trigger a conditionally started Workflow on the Order to then Query the Line Item List and based on the conditions specified, continue along with the process or stop and wait to be invoked again. 
    • This can fail for many of the same reasons as the method 1 can fail, but with the additional silliness of potentially having to clean up 'bad' increments / updates. If you're incrementing a value of a column named something like [Line Items Completed], you first have to read the value of column from the Line Item, then increment it, then send it back. This can completely fail due to Race Conditions

As stated, both of these *can* run into Race Conditions (meaning that there is a chance that two or more items can both reach a valid state at the same time, and attempt to make changes at the same time which will result in one of the updates being *missed* or an error being thrown). While that might seem like a pedantic thing to care about, I would like to build things in such a way as to make sure that the possibility of that happening is reduced to 0. As we have all found out (the hard way):


If it can happen, your users will eventually find a way to make it happen!



Do any of you all have design patterns that you have created to solve this problem in a straight forward and completely air-tight way? Maybe I'm going about it all wrong, but the only way to know is to ask! I believe that I DO have a new approach that will fix it, but it might be a little silly and over the top, so I'd rather ask the community first and if nothing seems satisfactory, I'll just release my own way of solving this even though it's kinda overkill (maybe)


Looking forward to having this discussion. 


Thank you all for you time!