scheduling buildings

I'm a stake website administrator. With the classic website there was an actual resources calendar separate from the general stake calendar. We could post events on the stake calendar, and then go to the resources calendar to reserve a building or the cultural hall, etc...

With the new calendar system, I'm not following how the process works for scheduling church buildings. No problems with creating new events, but how does a building coordinator maintain control of the actual buildings and booking rooms, etc??

Please help me understand how a building scheduler is supposed to manage his/her buildings via the new calendar system.
thank you

Moderator note: The thread has been moved to the proper sub-forum.

The very short answer: you don't. With the new calendar, the scheduling of buildings has moved from the "centralized model" to a "distributed model". Individual calendar editors (which should generally be responsible members/leaders, not the general membership) are able to schedule the building by selecting the location on a first come/first served basis.

As a Building Scheduler, your role is primarily to referee conflicts and settings reservations to determine what nights is a given "ward's night" for scheduling.

Odds are you'd probably have access to a "private events" calendar to allow you schedule weddings and such. Whatever you do, don't use the "Reservations" function to block off times for events. "Reservations" are not designed for that and it's too easy to create a double-booking.

The calendar help provides good instruction on all aspects of the calendar.

Why wouldn't you use the "Blocked - Location Unavailable" option to reserve a location for non-church events like wedding receptions? Seems better than a private calendar for stuff like that.

mnmpeterson wrote:Why wouldn't you use the "Blocked - Location Unavailable" option to reserve a location for non-church events like wedding receptions? Seems better than a private calendar for stuff like that.

One problem with any kind of reservation (even the "Blocked" variety) being used to book a building is that any building scheduler can override the reservation by creating an event, and there will be no warning that a reservation just became irrelevant because an event superseded it. Indeed, even if there is only one building scheduler, he might happen to schedule an event that overrides a reservation he created earlier, but has since forgotten about.

Reservations are second-class citizens when it comes to actually booking a location -- only an event insures that the location is truly booked.

mnmpeterson wrote:Why wouldn't you use the "Blocked - Location Unavailable" option to reserve a location for non-church events like wedding receptions? Seems better than a private calendar for stuff like that.

That is an option if there is only one building scheduler for the location. But when there is more than one building scheduler for a location then there is potential the building scheduler who did not create the "Blocked - Location Unavailable" reservation could create an event (assuming he/she is a calendar editor) over top of the reservation. The potential for more than one building scheduler at a location is beyond the control of the building scheduler since any default stake administrator can assign anyone or themselves to that position. Creating an event on a calendar is the only method resources can be scheduled to prevent double booking.

jdlessley wrote:That is an option if there is only one building scheduler for the location.

And only if that building scheduler never schedules events. Because the system gives them no warning if they schedule a event on top of a reservation. There's nothing to protect the Building Scheduler from himself.

aebrown wrote:One problem with any kind of reservation (even the "Blocked" variety) being used to book a building is that any building scheduler can override the reservation by creating an event, and there will be no warning that a reservation just became irrelevant because an event superseded it. Indeed, even if there is only one building scheduler, he might happen to schedule an event that overrides a reservation he created earlier, but has since forgotten about.

Reservations are second-class citizens when it comes to actually booking a location -- only an event insures that the location is truly booked.

jdlessley wrote:That is an option if there is only one building scheduler for the location. But when there is more than one building scheduler for a location then there is potential the building scheduler who did not create the "Blocked - Location Unavailable" reservation could create an event (assuming he/she is a calendar editor) over top of the reservation. The potential for more than one building scheduler at a location is beyond the control of the building scheduler since any default stake administrator can assign anyone or themselves to that position. Creating an event on a calendar is the only method resources can be scheduled to prevent double booking.

So the reason for not using Blocked for non-church activities is because a building scheduler can ignore the Blocked reservation and schedule a location over it?

That's something a building scheduler could do all along. If they tracked a building's schedule on paper or used the old resource calendar there was no mechanism to prevent them from double booking if they didn't pay attention.

RussellHltn wrote:And only if that building scheduler never schedules events. Because the system gives them no warning if they schedule a event on top of a reservation. There's nothing to protect the Building Scheduler from himself.

Actually it does "Warn" you about potential conflicts -- including Blocked reservations. It just doesn't prevent a scheduler from creating the event.

mnmpeterson wrote:So the reason for not using Blocked for non-church activities is because a building scheduler can ignore the Blocked reservation and schedule a location over it?

That's something a building scheduler could do all along. If they tracked a building's schedule on paper or used the old resource calendar there was no mechanism to prevent them from double booking if they didn't pay attention.

That's true, but what under the old centralized model there was never more than one building scheduler, and that building scheduler typically only had one system. Now there can be multiple building schedulers (and we've seen many posts that show that many stakes have multiple schedulers -- often a designated building scheduler plus one or more stake admins who add themselves as building schedulers for convenience). Each of these building schedulers has the ability to override reservations, and most of them are set up as calendar editors or administrators who now have two ways to book a location (reservations and events) -- if you choose to consider a reservation as "booking" a location.

In any case, each stake is certainly welcome to book locations as it sees fit. It's just that some of us have learned through sad experience (some personal, some through helping many people on this forum) that using reservations to book locations can very easily lead to double booking and a lot of grief.

mnmpeterson wrote:Actually it does "Warn" you about potential conflicts -- including Blocked reservations. It just doesn't prevent a scheduler from creating the event.

True, but that list of potential conflicts is often so long that it's rather impractical to review it (particularly for repeating events). So the warning mechanism is very easy to ignore because it casts such a wide net.

aebrown wrote:That's true, but what under the old centralized model there was never more than one building scheduler, and that building scheduler typically only had one system.

Actually the old system had the capacity for multiple schedulers. In fact all stake administrators were set as schedulers for each resource calendar by default. It just had one person who would be notified by email when a new request was submitted for approval. At least the new system doesn't make all stake administrators schedulers by default.

aebrown wrote:True, but that list of potential conflicts is often so long that it's rather impractical to review it (particularly for repeating events). So the warning mechanism is very easy to ignore because it casts such a wide net.

I was just pointing out that it does Warn you. A nice enhancement would be to highlight Blocked conflicts for schedulers creating events over top so they would be better warned.