Tips & How-To — MultiDatePick for Salesforce

Blocking dates & times

Grey out dates or time ranges so they can't be booked — from a separate "closure" object you control.

Point the component at any object that holds your closures (e.g. Office_Closure__c) with the blocked-dates properties. Each closure record becomes unavailable in the picker.

Property	What it does
`blockedDatesSourceObject`	The object holding closures (e.g. `Office_Closure__c`).
`blockedDatesDateField`	The Date field on that object.
`blockedDatesStartTimeField` / `blockedDatesEndTimeField`	Optional Time fields. Set both for partial-day blocks; leave them off for whole-day.
`blockedDatesResourceField`	Optional lookup. Set it to block only one resource; leave blank to block all resources (region-wide).
`blockedDatesFilterField` / `blockedDatesFilterValue`	Optional. Scope closures by a field value (e.g. `Region__c = North`), or by the parent record.

Whole-day vs partial-day — how each shows: a closure record without start/end times is whole-day → it greys out the whole calendar date. A closure with a start and end time is partial-day → it greys only those time slots in the grid (visible once a date is selected). Rule of thumb: if you're using the time grid, you want partial-day blocks; whole-day only makes sense for date-only pickers.

A whole-day closure disables the date even if it already has bookings — a closed date isn't bookable. To let customers create closures themselves (e.g. an owner blocking their own time), drop a Date Time component pointed at the closure object on an internal page or Experience site.

Capacity & availability

Let more than one booking share a slot, with live "X of Y" badges and conflict handling.

Property	What it does
`capacityField`	A Number field on the resource (e.g. `Capacity__c = 5`). Slots show "3 of 5 left" and stop accepting bookings once full.
`showAvailabilityCount`	Turn the X/Y badges on.
`capacityAggregation`	`Combined` (sum across resources) or `Distinct` (count one logical event booked across several resources as one).
`conflictBehavior`	`block` (a taken slot can't be selected), `skip` (save the open slots, skip the taken), or `allow` (overbook past capacity).

Tip: capacity needs the booking start/end time fields configured — without them there are no slots to count against. If a capacity grid shows nothing, check that the time fields are mapped.

Status colors & filtering

Color-code bookings by your own picklist values, hide some statuses, and limit what end users can set.

Property	What it does
`statusField`	A picklist on the booking record (e.g. `Status__c` = Confirmed / Tentative / Cancelled).
`statusColors`	Map each value to a color. Leave blank to auto-assign a palette by picklist position.
`statusColorDisplay`	Where colors show: `calendar`, `grid`, or `both`. (Leave empty for no colors — e.g. a clean customer view.)
`hideBookingsWithStatus`	Admin-side: hide records with these statuses entirely (e.g. `No-Show,Cancelled`) — from the grid and capacity counts.
`selectableStatuses`	Limit which statuses an end user can choose (e.g. clients can only set `Requested`), while staff see the full set.

Two views, one object: a clean customer page can use statusColorDisplay="" + selectableStatuses=Requested + hideBookingsWithStatus=No-Show,Cancelled, while a back-office page on the same data turns colors on and exposes every status.

Limiting what users can select

Cap how much a single user can pick — by dates or by time slots.

Property	What it does
`maxSelections`	Maximum number of dates a user can select. `0` = unlimited.
`maxTimeSlotSelection`	Maximum number of time slots a user can select in total, across all dates. `0` = unlimited. (Use `1` for "one appointment per person.")

Note: maxSelections caps dates, not slots — a user with maxSelections=1 could still pick several time slots on that one date. Add maxTimeSlotSelection when you need to cap the actual number of bookings.

Public "try it live" demos (guest access)

Expose a component on an Experience Cloud site so anyone can use it without logging in. Every link in this chain is required — and two of them fail silently.

Object permissions — give the site Guest User Read (and Create, if guests submit) on each object. (Guest licenses can't Edit — a "manage/edit" view is read-only for guests.)
Field-level security on every field the component touches — including resource business-hours fields and closure time fields. A missing FLS makes the resource/blocked-date query fail.
Sharing rules — a guest sharing rule (Read) so the Guest User can actually see the records. Object + field access alone isn't enough; "Secure guest user record access" forces this.
Apex class access to MultiDatePickController on the guest profile/permission set. Without it the component just shows empty with no error.
Activate the site — Publish is not the same as Activate. An un-activated site never serves the real experience to guests.

The two silent ones: missing Apex class access (the data call fails quietly) and an un-activated site (guests get a placeholder) produce no error message — so check them first when a public component looks empty even though the admin view works.

Combining components: you can place several components on one page (e.g. an owner "block times" calendar above a customer booker). They don't live-sync, so add a "refresh" prompt or button between sections so a block made above shows as greyed below.

More recipes

Browse ready-to-import configurations for dozens of scheduling use cases, or get notified when MultiDatePick goes live.

Browse the Config Library Notify Me at Launch