Events, Double Bookings and Conflicts, oh my...

[smorris]

"None of this is true of two events. Two events can never schedule the same resource at the same time."

We have 3 buildings in the stake. 2 of the 3 buldings had overlapping events for November 28th. 3 of the events were entered as entire facility for the entire day. 2 other events were entered as kitchen and cultural hall for a few hours on the same day. A total overlap in a system that said it can't happen.

There were no restrictions involved, all 5 were events. How does this happen?

[russellhltn]

My first response: are you sure this isn't a case of a duplicate building? My second response: Did they actually book the location and not use "other location" or use a locally-created calendar layer and called it "the building calendar"?

Can you post a screen shot of one of the buildings in week view with all calendars except that location turned off?

There have been isolated cases in the past where conflicts have been allowed, but we have to rule out user error first.

[smorris]

I have attached 5 jpg files using the snippet tool.

I can't see any difference in the events except the color of the event header.

On a separate note, the calendar "crashed" on my again while working on this. It gets a screen collision or overlapping text and you can't tell what you’re looking at. Exiting all browsers and getting back in is the only solution that sometimes works.... This is a different issue for a different forum I suspect.

[eblood66]

I have attached 5 jpg files using the snippet tool.

I can't see any difference in the events except the color of the event header.

Actually the entries with times are in fact restrictions and not events. You can tell because in the details view under Calendar it lists the building and not an actual calendar. The 'View Event' title is used for both events and restrictions so you can't tell by looking at the title. You can also tell because a restriction will say 'Reserved:' in the week view.

[Gary_Miller]

There were no restrictions involved, all 5 were events. How does this happen?

I can't see any difference in the events except the color of the event header.

Several of what you call events are actually restrictions. A restriction appears as a blank event lacking any color fill and will appear in the week view as a grey header and white body. Where as an event that is not on a calendar layer you have chosen to see or one for another unit will appear with a white header and a grey body.

It appears that when it come to privet events people are being directed to the Building Scheduler who then places an restriction on the calendar. This is due to the building scheduler not being able to put event on any calendar, unless they have editor rights at their wards level or the stake level, which is how the program is now designed. A restriction does not book/schedule the building it only allows for a specific unit to be able to place a event which in turn books/schedules the building.

[russellhltn]

A restriction does not book/schedule the building it only allows for a specific unit to be able to place a event which in turn books/schedules the building.

Furthermore, a restriction can be placed at any time and there is no warning about any conflict. So unless the Building Scheduler took the time to verify that the facility was really available, they might have been the one who created the conflict.

But it all comes back to using restrictions when it should have been an event.

[Gary_Miller]

But it all comes back to using restrictions when it should have been an event.

Which consistently seems to be the problem when someone comes on here spouting that events can be double booked.

[RandomEcho]

As Someone who has been a Building Scheduler for the last year and I have to say the way the system is currently designed is flawed. They assign a building scheduler who really has no ability other than to be a mediator and provide conflict resolution. As already stated a Restriction(Reservation was a better name not sure why they changed it) will hold the spot for that unit to add an event if setup correctly at the stake level you can specify the Unit that has the reservation, but that doesn't stop another auxiliary in that unit from taking their reservation if they don't fill in with the Event.

The Struggle is in getting people properly Trained on how to use the system. I did a handout with screen shots and very clear instructions that I sent to all who had the ability to schedule an event and still have people who don't get it.

[aebrown]

As Someone who has been a Building Scheduler for the last year and I have to say the way the system is currently designed is flawed. They assign a building scheduler who really has no ability other than to be a mediator and provide conflict resolution.

I think the role works fine, but I'd certainly agree that the title of "Building Scheduler" doesn't fit the role very well. Much of the confusion I see comes from people making incorrect assumptions about what a "Building Scheduler" can or should do, and much of that confusion comes from the misleading title.

As already stated a Restriction(Reservation was a better name not sure why they changed it) will hold the spot for that unit to add an event if setup correctly at the stake level you can specify the Unit that has the reservation, but that doesn't stop another auxiliary in that unit from taking their reservation if they don't fill in with the Event.

I beg to differ -- the term "Restriction" is far less confusing than "Reservation", since we're not really talking about a reservation in the sense that people often think about in other contexts. If I have a hotel reservation, I assume I can show up and I will have a room. But if I have a "Restriction" on the Calendar on LDS.org, I have no guarantee that I have any room at all -- only an event will provide that assurance. Calling it a "Reservation" was completely misleading.

And trying to use a Restriction to hold a spot for a particular event isn't very effective, anyway. Restrictions work fine for recurring priorities (such as "Ward A gets the cultural hall every 2nd and 4th Tuesday") but there's really no reason to use a restriction for a single event; it's much better to just create the event and be done with it.

The Struggle is in getting people properly Trained on how to use the system. I did a handout with screen shots and very clear instructions that I sent to all who had the ability to schedule an event and still have people who don't get it.

In my experience, at least one member of a presidency will get it, and it works well to just let that person schedule events. You're certainly right that training is important.

[russellhltn]

They assign a building scheduler who really has no ability other than to be a mediator and provide conflict resolution.

Correct.

As already stated a Restriction(Reservation was a better name not sure why they changed it)

You kinda answered your own question. In the "old way" a "Reservation" meant that the building/rooms were set aside for a specific event. It was causing confusion when people thought the building/room was "reserved" only to find out that someone else was able to create a conflicting event. Many of us here lobbied for the change to "restriction" to get people to better understand what the system did. It "restricts" who can schedule an event.

The Struggle is in getting people properly Trained on how to use the system. I did a handout with screen shots and very clear instructions that I sent to all who had the ability to schedule an event and still have people who don't get it.

It's a bit daunting to set up (what calendars should be created, etc), but once up and running, it's not at all hard to use. I suspect the real problem is motivational. I see two angles on taking care of that. First is building scheduling - "if you don't add an event, I can't guarantee you the room" is pretty motivational.

The second is to advertise the Sync ability of the calendar. Once leaders realize that they can get events into the member's personal calendars, they'd be much more diligent in keeping it up to date.