Hi @gianplod 

There is no way to ensure the outcome when 2 workflow run at the same time.

WF1 - query balance AvailableSeats. retrieve 80

WF2 - query balance AvailableSeats. retrieve 80

WF2 - update AvailableSeats. set 79

WF1 - update AvailableSeats. set 79

I had a workflow that sets a sequential Running No to each application form. There were several occurrences of duplicates Running No. There is simple no way to avoid this. I have to manually correct the Running No. In the end, I scrap the the Running No and just use the List ID as the running no. There were no further issues of duplicates Running No. 

An alternative

Use one List for each Course Instance (Course X, Date Y, Time Z, Venue A, Room B)

Per enrollment, Add a User using Create List Item action into the List.

Get the List ID for that item. 

If the List ID is Less Than or Equals AvailableSeats (lets say 80), User is confirmed. Status = Accepted

If the List ID exceeds AvailableSeats, User is not confirmed. Instead of deleting the User, we just retain them as reserves, User is on WaitList. Status = WaitList.

When 2 users apply, (luck of draw when workflow runs and add user to list), whoever is ID==80 is Accepted and whoever ID==81 is on WaitList.

We are using SharePoint capability which wouldn't allow for 2 items with the same ID 80

Cheers

This is something that Nintex struggles with, but out of the necessity of needing something similar solution (Many potential item statuses that need to inform a single central parent item) in my own environment, I might be able to help. 

Really I need to know a little more about what's happening during the Registration portion. Are your users creating List Items that have a Nintex Form + Repeating Section where they can enter in 'n' number of Enrollees? When they want to add more people do they edit the previous Item or create a new one? 

Depending on the way you're entering the info, my idea may or may not work, I just need to know a few more details about how the workflow that will run is actually be invoked.

If the stars align something like the solution I created here might work: https://community.nintex.com/t5/Nintex-for-SharePoint-Forum/Best-Practice-Question-Tracking-Multiple-Item-States/m-p/99891/highlight/true#M69647

Just know that I quite literally cannot guarantee that it works in your environment, but once I get some more details I will try to work up an example that you can follow along with. I've been meaning to do a proper write up about this method / approach for a while, so better now than never! 

Hi @Garrett, @MegaJerk ,

Thank you both for your responses.

@Garrett nice idea, not applicable in my case as I would end up having A LOT of lists, but I like the approach.

@MegaJerk I took a look at your solution and I think it is an enhanced version of the my idea regarding the use of a Call Web Service to trigger the workflow that updates the capacity directly in the list that contains all of the courses dates. We built a workflow and added a state machine to re try in case the wf is already running (for the cases in which the registrations are made at about the same time).

Right now, I gave it a try with some JavaScript code on the submit button, which basically makes a GET and a POST call to update the capacity in the courses dates' list. It worked fine for two simultaneous registrations, but no for more (however, given the number of people interacting with the tool, it would be REALLY unlikely to have 3 or more people SIMULTANEOUSLY clicking submit when registering employees for a course).

I'm still having some issues to prevent the form from uploading when the capacity is 0 or less than the number of registered employees (at submit time), but I guess there's some way of achieving so.

Other good idea that came up from the team, is to put every registered employee in a "Pending Approval" state, and have an "orchestrator" Site workflow running daily and calculating the new capacity by substracting each employee individually. This would also help to implement a waitlist queue.