A member of Loqode School recently had a question about booking/scheduling functionality in Glide, so I thought I’d share here too.
For this particular use-case the time slots are exactly 30 minutes each and span from 8am to 4pm… But you can very easily tweak this solution to suit your needs (e.g. variable length bookings).
Of course there are plenty of alternate ways to achieve the same functionality, but this appears to be a very simple option. It utilises what is known as a “Helper Table” (shoutout to @Darren_Murphy) to check for double-bookings on the fly and only allows users to select time slots that are free.
Very nice - love your tutorials, always clean and easy to follow.
A couple of comments/tips, because you know I can’t help myself
Those two template columns you have in the Helper table for the UserID and Name - it appears that you don’t actually use them anywhere? (or did I miss something?)
When you open the form, you use a Show New Screen action. Whilst that is fine, it does limit you to only being able to create bookings whilst in the context of that screen. What I like to do is create a Single Value → First → Helper Table → Whole Row in the User Profile table, and then use a Show Details (not Show New) screen via that column. Doing it that way essentially gives you a reusable Custom Form that you can call from anywhere in the App.
Clearing the User Specific columns in the Form. I like to do this as the form is opened, rather than when the form is submitted. Functionally it is the same, but it does eliminate the possibility of any race conditions where the columns might be cleared before the new row is created.
Date Formatting: this is one to watch out for, especially when you are using Dates in relations. The thing is, every users device could format the dates in a slightly different way depending on their device/browser regional settings, and this can result in unexpected (and broken) behaviour. The best way to avoid that is to first convert the dates to an integer: Year(Date) * 10000 + Month(Date) * 100 + Day(Date), which gives you something like 20230615. And then use that in your template. So that would become 20230615 8:30 am. Doing it that way will guarantee that your relations will always work for all users.
And I’d expect nothing less! Always appreciate your input.
Your 100% correct in saying the UserID and Name columns aren’t used… Forgot to remove them when simplifying the app, and while recording I went on full auto-pilot mode explaining everything column by column without the penny dropping that they were now redundant You have a keen eye!
Thats a great idea, thanks for explaining
Makes sense and it’s a very simple change to make.
I’d normally use Luxon (Other > Date & Time > Format Date) to standardise the dates but I kept it simple for the tutorial in order to get the point across, but you’re correct in pointing that out
I’ve even had inconsistent results with that one in the past. When it was first added to Glide it seemed to be particularly buggy so I got turned right off it. It might be better now, I’m not sure. I just avoid it because I find that I can almost always get what I need with a bit of Date math
Interesting! I’ve used it sporadically for the past 5-6 months and haven’t come across any bugs yet but I’ll definitely keep an eye out. I wonder if anyone else has dealt with issues/inconsistencies with it lately…
Thank you for pointing it out though, good information to have on hand. I’ll watch for any oddities in the future… And if it’s relation-based and mission critical then something like your simple math solution may be the safest bet.
I have used both methods for a long time and they both work fine so far. In the beginning, when the Format Date plugin did not exist, the trick to convert the dates to an integer was something mandatory but I can bet that it works without problems currently.
Furthermore, I think that since the “Respect Time Zones” feature was released, any relation that uses 2 date columns will work just fine if both have the “Respect Time Zones” feature enabled so, there is no need to use the trick.
Technically, which method is faster to sort/lookup data if the key field is a number or a text? … a number!
When your dataset is small, you can’t see the difference in response time, but if you have more than 100k+ rows, the improvement is noticeable. In short and as advice: do not rule out the trick at all!
In this case, no. You would actually wind up with duplicate bookings. Last man in only happens when you have two or more users trying to update existing rows. In this case we are adding new rows - and there is nothing going on server side to detect/prevent duplicates - so that’s what we’ll get.
I’m afraid that won’t work. The challenge is that all of those calculations happen independently on each users device, and potentially at the same time. So every user could perform that check, and because they all haven’t synced up yet, they all pass, and you still wind up with duplicate bookings.
The only way to reliably deal with this situation is to delegate the allocation of the bookings to a 3rd party, eg. Make. Then they can be queued and handled sequentially, with a Make scenario checking for duplicates before adding each new booking.