Showing results for 
Search instead for 
Did you mean: 
Nintex Newbie

Best Practice Question – Tracking Multiple Item States

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!

0 Kudos
4 Replies
Nintex Newbie

Re: Best Practice Question – Tracking Multiple Item States


Great write up.  I understand the problem. It's gross, haha.

All of the options that immediately jump to mind won't work because we have an unknown amount of items. 

I have the dumbest idea. What if:

1. Grab all line items

2. Put all line items into new items

3. Grab ID of each, start looping & start workflow on each item ... however - first we make sure we pass a unique ID from our Order Form onto each new line item.

Like, Order OR-123 but Line Item OR-123-01, for example.  Then, of course, you'd have a status column hidden somewhere within each Line Item. 

Then you could have a third workflow - a Site workflow - that runs daily or hourly or whatever, and combs through Orders that are not "Complete", picks up the Order Form ID, queries the Line Items list for that Order ID, then checks the status - and triggers the final workflow if all are equal to "Complete". 

I ... think that would do it? I mean it's a bit messy, but, it gets the job done. And then it's still basically the Order Form managing the Line Items and not the other way around.

Nintex Newbie

Re: Best Practice Question – Tracking Multiple Item States

from my point of view, for this kind of scenario the most suitable approach would be a scheduled site workflow.

it would first check what orders are in an ACTIVE status and then for those check status of single line items. if they already met required stop state then proceed further on with next order processing step.

Nintex Newbie

Re: Best Practice Question – Tracking Multiple Item States

(This is a reply to both Marian Hatala‌ and Rhia Wieclawek‌ - I was on vacation for 2 weeks and so I stayed very very far away from all things Nintex (or at least as far as I could ))

Rhia Wieclawek: Actually, the Line Items from the Repeating Section in the Order are given both a unique ID and are being created as actual List Items on a different site, so that part's done!

Rhia Wieclawek & Marian Hatala: The only problem I have with a scheduled workflow is that it is not immediate. I thought about doing that first, but it wouldn't be acceptable for how work needs to get from point A -> B as quickly as possible. 

That being said though... I guess nothing stops me from using a tighter window for the schedule, but because I've never used this type of workflow, I don't know the impacts or implications for setting it up to run every 5 or 10 minutes. Or is that crazy


In a day or two I'll try to come back here and flesh out my idea for approaching this in as close to real-time as possible. But being that I have just arrived back, it's putting out fires time for me   

Thank you both for your replies! 

0 Kudos
Nintex Newbie

Re: Best Practice Question – Tracking Multiple Item States

The only problem I have with a scheduled workflow is that it is not immediate.

IMHO, it's better solution that notifies/advance to next step a minute later but is reliable, than quick unreliable one.

 I don't know the impacts or implications for setting it up to run every 5 or 10 minutes. 

usually that doesn't mean any big (negative) impact. CAML queries are quite fast. I think for simple check of item's status for bunch of order you even not need any looping, it could be done with just two queries.

of course it depends on overall list(s) size, number of open orders/order items, etc. but that's valid in general.