Five Calendar Views, One Salesforce Component
A month grid is the wrong shape for half the scheduling questions people actually ask. Here is why we added four more views, and how choosing between them became a config field instead of a rebuild.
Every calendar starts as a month grid, because that is what the word makes you picture. Then people start asking questions it cannot answer. "Who is free Thursday afternoon?" "Is Room 4 booked solid next week?" "Which technician is over capacity?" The grid holds all of that data. It just makes you hunt for it.
MultiDatePick now renders the same records five ways. One component, one set of field mappings, one save path, and a view property that changes the layout.
The five views, and the question each one answers
| View | The question it answers | Shape |
|---|---|---|
| Calendar | What is happening on the 14th? | A month at a time, status colors per day. The default, and still the right answer most of the time. |
| Timeline | Which resource is free, and when? | Resources down the side, dates across the top. A multi-day booking draws as one continuous bar. |
| Week | Who is free Thursday at 2pm? | Seven days across, your business hours down. Drag across days and down hours at the same time. |
| Utilization | Who is over capacity? | A heatmap of percentage-of-capacity used, per resource per day, green through red. |
| Agenda | What is next? | A flat chronological list of the next 60 days. Reads well on a phone and in a shift handover. |
Utilization and Agenda are read only by design: they answer a question rather than take a booking. The other three are fully interactive.
agendaFields picks the columns. Reads well on a phone.Why this is a configuration problem, not a feature request
The usual version of this story ends with a second component: its own fields, its own save logic, its own bugs. Here all five views read the same records through the same field mappings, honor the same conflict rules and blocked dates, and write through the same save path. Switching from Calendar to Timeline cannot change what a booking means, because there is only one definition of a booking.
Two properties control it:
view
Which layout the component opens on. One of calendar, timeline, week, utilization, agenda.
availableViews
A comma-separated list of the views the switcher offers. Leave it blank to offer all five, or narrow it to the two that make sense for this page.
So one component becomes three different tools. A recruiter's Interview Scheduling page opens on Week, because interviews are a time-of-day problem. A facilities manager's Room Booking page opens on Calendar with Timeline and Utilization alongside, because rooms are a capacity problem. A wall display opens on Agenda and offers nothing writable at all.
availableViews. That list only needs the extras, which removes a whole class of "I restricted the views and now my own default is gone" confusion.
The flexibility that matters is per placement, not per org
An org-wide calendar setting is close to useless, because one company is not asking one question. Sales wants next week. Operations wants next quarter. A shift manager wants today, by the hour. Finance wants a utilization number.
view is a property on the component, not a setting on the package. Put MultiDatePick on four record pages, a Flow screen, a Home page and a public Experience Cloud site, and each can be a different view of the same objects. No second install, no field mappings to keep in sync.
Timeline has two properties of its own:
| Property | What it does |
|---|---|
| timelineWindowDays | How many days are on screen at once. Defaults to 14. A full month of columns leaves each booking about twenty pixels wide and clips every label, so the window exists to keep the view readable. Set it to 0 if you genuinely want the whole month. |
| maxViewResources | How many resource rows to draw, busiest first. Keeps a list of eighty rooms from turning the view into a wall. |
When one resource has several overlapping bookings, its row collapses to a single strip with a count, and expands on click into one lane per booking. Density becomes something the user chooses rather than something the data inflicts on them.
Point the resource lookup at User and it becomes people scheduling
The resource lookup points at any object. Rooms gives you room booking. Equipment gives you checkout. Point it at User and every view above becomes a staffing tool: Timeline is a roster, Week is a shift grid, Utilization is a team capacity dashboard. Managers ask "who is over capacity" about people far more often than about rooms.
resourceObjectApiName set to User.businessHoursStartField and businessHoursEndField to fields on User, the Week grid honors each person's own working hours instead of one org-wide range.
There are two ready-made configs for exactly this in the library: Team Capacity Planning, which opens on the Utilization heatmap, and Staff Shift Roster, which opens on Timeline. Both use User as the resource.
Every config in the library now ships with a view already chosen
Picking a default view is a judgment call, and it is easier to copy one than to make one. So every config in the Config Library now specify both a default view and a switcher list, chosen for what each config is actually for:
- Interview and appointment configs default to Week
- Room, desk, fleet and lab configs offer Timeline and Utilization
- Date-range configs like PTO and blackout dates offer Timeline, where a multi-day record draws as one bar
- Date-only configs stay on Calendar with Agenda as the read-only companion
- Utilization only appears where a capacity field exists, because without one it shows raw counts
- Defaults are always a writable view, since a read-only default would break the config's primary action
Import any of them, remap the field names to your own schema, and the view choice comes along with it.
One component. Five views. No second install.
Browse the config library and see which view each scenario opens on.
Browse the Config Library Notify Me at LaunchComing to AppExchange in 2026. One plan, every feature included.