Concurrent user update design

[jjc]

Dear AppSheet Community,

I'm developing a booking app, the booking process works as follows.

1. User open view of available slots (table A)
2. Trigger a sequence of actions
   • Add a new booking record row (table B) with the appointment ID from table A which checks if the desired appointment row is available from table A using formula ISBLANK() and COUNT()
   • Update the table A row of appointment ID with user if the booking status is true in table B 
   • Redirect to a view of booking record (table B) which shows the booking result status

I'm testing with 2 methods.

1. Opening view of available slots and then manually update cell of desired appointment user directly on the spreadsheet before clicking the booking button
   • The app still updates the row even it's supposed to detect unavailability by formulas which is not what I'm expecting
2. Open two preview windows with different identities then book in order
   • The first user will update the appointment row, then the later user identity cover its record afterwards which is also not what I'm expecting
     (Just like what here said: https://support.google.com/appsheet/answer/10104702?hl=en)

I guess I need to sync data after the user triggered the action sequence to conduct a valid condition check before updating appointment row? But I'm just unable to do it.

Anyone know how to achieve this or is there a better design?

The goal is to minimize concurrent booking conflict and provide better user experience.

Thanks a lot 🙏

[Marc_Dillon]

---

@jjc wrote:

Update the table A row of appointment ID with user if the booking status is true in table B 

---

Make this Action look at the related bookings from tableB, and have it only select the one with the earliest creation timestamp. Then trigger this Action with an API call instead of in the current app session, which will force it to load all available records, even if the current app session hasn't loaded them yet.

* a wait condition in a Bot, before the Action is executed, might also work instead of an API call, and would be easier to set up, but I'm just not 100% sure there.

Edit: to elaborate some more:

1. User1 and User2 load the app at the same time.
2. User1 submits a tableB record to book a slot.
3. The action executes, sees only the single tableB record, and pushes User1 into the tableA slot.
4. Some time later, without syncing first, User2 submits a tableB record to book the same slot.
5. The action is executed in a new app session, where it can see both tableB records, but still only selects the one from user1 because it has an earlier timestamp, and just re-pushes user1 into the tableA slot.