MultiDatePick for Salesforce Developers and Architects
How the calendar fits into your org: where settings live, what a Screen Flow gets back, the Apex types your flows can loop, how security works, and how to move configs between orgs.
MultiDatePick is built so admins never need a developer. This page is for the times a developer or architect is involved anyway: reviewing the package, building flows around it, or moving its setup through sandboxes.
What ships in the package
| Piece | What it does |
|---|---|
| Date component | Pick many dates, drag ranges, add recurring patterns. Saves one record per date or per range, or returns the dates to a Screen Flow. |
| Date Time component | Dates plus time slots, shared or per date, with conflict checks. Saves one record per date, per time block, or a parent with sub-blocks. |
| Booking component | Book rooms, equipment, vehicles or people (any object, including User) with capacity, business hours, blocked days and booking rules. |
| Setup Wizard | A Lightning tab that writes configs, with a live preview and JSON import and export. |
| Flow actions | Parse Date Entries from JSON and Format MultiDatePick Time Range, for flows that save the records themselves. |
| Permission sets | MultiDatePick - Setup, MultiDatePick - User, MultiDatePick - All Access, and MultiDatePick - Guest for public sites. |
Where the settings live
Every saved setup is a Custom Metadata record: Config__mdt holds the settings, and Config_Extension__mdt holds newer ones as JSON in Settings__c. A placement on a page or a flow screen names its config in Config Name; any property you also set on the placement overrides the config's text and number values.
- Deployable: configs are metadata, so they move with change sets, the Salesforce CLI or your CI/CD pipeline like any other metadata.
- Portable: the wizard exports a config as JSON and imports it into another org, mapping any object or field that is missing there.
- Reviewable: one record per setup, readable in Setup, so a change shows up in a diff.
Your data stays your data
The calendar reads and writes your own objects. There is no MultiDatePick data model to sync, no external service and no callout: picks become ordinary records on the object you choose, with the fields you map (date, end date, start and end time, status, name, resource). Triggers, flows, validation rules and reports on those objects keep working as usual.
Screen Flow outputs
Put a component on a flow screen, set Config Name, and read these after the screen:
| Output | Type | What it holds |
|---|---|---|
| Selected Dates | Text collection | Each picked date as YYYY-MM-DD. Loop it to create one record per date. |
| Date Ranges JSON | Text | Picked ranges, each with a start and end date, when Output Date Ranges as JSON is on. |
| Dates With Times JSON | Text | Date Time component: each date with its start and end time. |
| Successful Bookings Count | Number | Booking component: how many bookings the save created. |
Pass a record into Parent Record Id and the calendar shows that record's existing dates and can save new ones itself. To have the flow save instead, choose My flow saves them in the wizard: the calendar then hides its own Save button and only hands the picks to the flow.
Looping picks in a flow
For JSON outputs, the Parse Date Entries from JSON action turns the text into a collection your flow can loop, with no Apex to write:
| Apex-defined type | Fields |
|---|---|
MultiDatePickEntryCollection | data (the entries), totalCount, success, errorMessage |
MultiDatePickEntry | fromDate, toDate, startTime, endTime, resourceId, resourceName, bookingStatus, relatedRecordId, label |
The Screen Flow Guide walks through the loop step by step, and the Flow loops post has three starter flows you can deploy with VS Code.
Security model
- Every query and save runs in user mode: object permissions, field-level security and sharing apply to the person using the calendar, including guest users on public sites.
- Nothing leaves the org: no callouts, no external servers, no subprocessors.
- Passed the Salesforce Security Review. Details on the Trust & Security page.
- Accessibility: a VPAT 2.5 report against WCAG 2.1 A and AA, on the Accessibility page.
Moving a setup from sandbox to production
- Build and test in a sandbox with the Setup Wizard.
- Move the config: deploy its
Config__mdtandConfig_Extension__mdtrecords with your usual tool, or export it as JSON from the wizard and import it in production. - Move the page or flow that uses it. Placements refer to the config by name, so nothing else changes.
- Assign permission sets to the people who use it, and MultiDatePick - Guest on public sites.
Questions developers ask
Do I need to write Apex to use MultiDatePick?
No. The components load and save records themselves, and flows that save on their own use the packaged Parse Date Entries from JSON action instead of custom Apex.
Can configs go through CI/CD?
Yes. Each config is a Custom Metadata record (Config__mdt, plus Config_Extension__mdt for newer settings), so it deploys like any other metadata.
Does MultiDatePick add objects for my data?
No. It saves to the objects you choose, so your records, automation and reports stay where they are.
How does it handle time zones and languages?
Dates and times follow each user's Salesforce time zone and locale, and the interface is translated into nine languages.