I do believe that if you had just a single GSheet, then you could solve your problem. I’m not sure what your current user journey looks like, but it would need to be a two step process, with a short delay in between each step. Here is what I’m envisaging:
- When a user taps a button to claim a collectable, you put them into a “holding pattern”
- The button that they tap sends a webhook to Integromat with two values: the UserID, and the ID (RowID?) of the item they are attempting to claim.
- Integromat writes 3 values into a new row in your GSheet: the UserID, the ItemID, and a now() time stamp. NB: This is the key - that time stamp comes from Integromat, NOT from any of your users. So it’s a single point of reference.
- You build a multi-relation from your Glide Table to the GSheet, using a template that combines the UserID and ItemID
- Then you use a rollup to take the earliest time stamp through that multi-relation.
- The next step is to build a single relation back to the GSheet using a template that combines the UserID and the ItemD
- Then a Lookup through that relation to fetch the actual time stamp value for each user that’s tried to claim the item.
- You now have two time stamp values in your Glide Table: 1) The earliest time stamp via the rollup, and 2) The actual time stamp for each user, via the lookup
- Only one of your users actual time stamps will match the earliest, so that user becomes your winner.
- Present that user with a button that adds the new row, with the incremented ID, and present the rest with a “bad luck, try again next time” message.
The rows in the GSheet are merely transactional, and are only needed until such time as the process for each item is completed, so you could clean those out on a regular basis.