Building a Calendar Time Slot Picker in Salesforce
Salesforce gives you a date picker and a time field. It does not give you a grid of selectable slots. Here is what that actually takes, and how to avoid building it yourself.
A time slot picker is a specific interface: a calendar where you choose a day, and a grid underneath showing that day broken into bookable intervals, with the taken ones visibly unavailable. Everyone recognizes it, because every booking site on the internet uses it. Salesforce does not ship one.
What Salesforce actually gives you
A standard Date/Time field renders as a date input plus a time dropdown. It is a form control, and it has no idea what else is booked. Nothing stops a user selecting a slot that is already gone, because the field does not know other records exist. That check happens later, in a validation rule or a flow, after the user has already committed to a choice.
That is the fundamental gap. A time slot picker is not a nicer date field. It is a component that queries existing records before the user chooses, and only offers what is genuinely free.
What a real slot picker has to do
| Requirement | Standard fields | With MultiDatePick |
|---|---|---|
| Divide the day into intervals | No concept of intervals | 15, 30, or 60 minute slots |
| Know the working day | Any time is valid | Business hours from the resource record |
| Show what is taken | Nothing is shown | Existing bookings drawn on the grid |
| Handle several people per slot | Not expressible | Capacity with a live X/Y badge |
| Different times on different days | One field, one value | Per-date time mode |
Why building it yourself is more work than it looks
The rendering is the easy part. The parts that consume the time are the ones nobody scopes:
- Querying existing bookings efficiently without blowing governor limits when someone opens a two-month view
- Overlap math, which is fiddly the moment bookings can be different lengths
- Timezones, because the running user's timezone and the record's are not always the same
- Race conditions, when two people are looking at the same free slot at the same moment
- Field-level security, so the component respects what the running user can actually see
- Accessibility, because a grid of clickable divs is not keyboard navigable by default
That last one is worth dwelling on. A slot grid needs proper ARIA grid semantics, arrow-key navigation, and a state that is conveyed by more than color. It is the part most in-house builds skip, and the part a procurement review asks about.
Grouping slots so people can actually scan them
A 9-to-5 day at 15 minute intervals is 32 slots. Presented as a flat list, that is a wall. Grouping by period (morning, afternoon, evening) turns it into three short scannable blocks, which matters more than it sounds when the person choosing is a customer on a phone.
When you do not need the calendar at all
Sometimes the date is already implied. On a record page for an appointment that already has a date, showing a month calendar is redundant. Time Grid Only mode drops the calendar and shows just the slot grid for that one implied date, taken either from a field on the host record or passed in directly.