mmm, in our case the issue isn’t so much not knowing each users relative time, but more about dealing with the fact that we can have multiple users all trying to do the same thing at the same time, and because of sync delays they end up tripping over each other.
For example, record X becomes up for grabs, and 3 users all try to claim it at the same time. Because the initial change is local to each users device, it appears to each one that they’ve claimed X, and so they move on to the next step. But then everything eventually syncs up with Glide and only one of them ends up with X (which usually seems to be the last one in - which I guess makes sense), and so the other two get booted out and wonder what the hell is going on.
The way we’ve “solved” it is by deliberately introducing a delay, and a 3rd party to act as an arbitrator.
In this case the 3rd party is Integromat, but it could have just as easily been a bit of Apps Script. So what happens is:
- Users A, B & C all try and claim X at about the same time by tapping a button
- That button sends a webhook to Integromat, and our users are put in a holding pattern whilst we determine a “winner”
- Integromat writes two values back to the Users GSheet for each user: X, and a UTC timestamp (NOW())
- From another table, we build a relation to X, and then we do a rollup through that relation and take the earliest UTC timestamp
- That timestamp is then combined with X in a template, and that template is used to build another relation back to the Users sheet.
- Because only one of our users will have that exact timestamp, the relation will only be not empty for one user - and that user becomes our “winner”
So now I’m wondering whether or not your solution could be applied to the above scenario - what do you think? 