Sharepoint List "Lockout" edge case

[crispybits1977]

Hi all

Got an app that gets data from a Sharepoint list. It's basically a list of work experience opportunities for students, and they can jump in and pick and apply for one on the app itself (plus there's a whole bunch of other admin bits built in but they're not relevant to this question)

To prevent more than one student booking into the same position, I have a timer start when they click apply, and it spends 5-6 seconds doing some various staged writes to the sharepoint list to lock the opportunity, and then to write their email address to a field that specifies the lock is for them. I've managed to test it using 3 side by side browsers on 3 different accounts and generally it all works perfectly.

If they either apply for a role, or if they let the timer run out (60 seconds total) then it removes the lock from the sharepoint list item and blanks the field containing their email address, which frees it up for the next student to apply for (sometimes there are multiple openings at the same job).

The one thing I haven't been able to work out how to resolve is if someone does the first click to lock the item, and then before the timer runs down they lose connection, close their browser, or do something else funky that means the app can no longer communicate with the sharepoint list and unlock the job.

The only thing I can think of is maybe to trigger a flow with a 60 second delay step that then clears the lock and the email field. That way something keeps running even if the user themselves disconnects?

Is there a better way that anyone knows for a situation like this?

[crispybits1977 · Accepted solution]

Just went for the flow in the end - set a 61 second delay, and set a rand() variable that gets written to the SP list on lock so I know each flow will only ever over-ride the specific lock it's meant for - if someone triggers the flow and then applies, the flow obviously doesn't know that and keeps running. If someone else triggers a lock within that 61 seconds then their rand() number will be different and the flow ending won't cancel the second lock.

Would still be interested in hearing if anyone ever solved this a more elegant way, but just out of curiosity now rather than necessity.

[v-qiaqi-msft]

Hi @crispybits1977,

Thanks for your sharing.