Calendar permissions

We are struggling with fully implementing the new calendar. Building schedulers do not have the ability to edit any ward calendar but their own, so what is a building scheduler working with 2-4 wards supposed to do? They can't schedule anything for those other wards, or even see what those wards have in their calendars.

Furthermore, the stake has no visibility to ward calendars--again, except their own ward, which is not very helpful as we try to assist all wards in the stake. We can't even see what they're scheduling or how they're using the calendar. And they can't give us permissions to see it because permissions can only be granted to a member of the same ward. But the stake is the over-arching unit, so that makes no sense.

Bottom line: As stake clerk, I need to have and grant edit permissions to ANY member of my stake (preferrably by calling, not name) on ANY calendar in the stake, including ANY ward calendar. These permissions include the stake clerk, the stake presidency member over calendars, the high councilor over calendars, and the building schedulers. Otherwise, the burden is on each ward to schedule events and resolve conflicts--even though they can't see the other ward calendars sharing their same building.

davelef wrote:We are struggling with fully implementing the new calendar. Building schedulers do not have the ability to edit any ward calendar but their own, so what is a building scheduler working with 2-4 wards supposed to do?

Building schedulers do have the ability to edit any event on any calendar, as long as the event is scheduled for their assigned building. Such permission is important for conflict resolution.

davelef wrote:They can't schedule anything for those other wards....

Building schedulers have no ability to create new events, but that is not necessary -- wards should be creating the events. Ward events need to be on a ward calendar, and ward calendar editors and administrators can put them there. They don't need any help from the building scheduler to do that.

davelef wrote:...or even see what those wards have in their calendars.

Any member of any ward assigned to the building can see every event that uses that building. They just need to go into Week view and check the box by that building under Available Locations. Of course, the building scheduler can do that, too.

davelef wrote:Furthermore, the stake has no visibility to ward calendars--again, except their own ward, which is not very helpful as we try to assist all wards in the stake. We can't even see what they're scheduling or how they're using the calendar. And they can't give us permissions to see it because permissions can only be granted to a member of the same ward. But the stake is the over-arching unit, so that makes no sense.

I can see how it would be helpful for the stake to see what wards are doing for training purposes, but that's about the only valid reason I can see.

davelef wrote:Bottom line: As stake clerk, I need to have and grant edit permissions to ANY member of my stake (preferrably by calling, not name) on ANY calendar in the stake, including ANY ward calendar. These permissions include the stake clerk, the stake presidency member over calendars, the high councilor over calendars, and the building schedulers.

Our stake is functioning just fine without those permissions. I'd recommend that you read About scheduling events and consider how the distributed scheduling model can work in your stake.

davelef wrote:Otherwise, the burden is on each ward to schedule events and resolve conflicts--even though they can't see the other ward calendars sharing their same building.

Calendar editors in each ward schedule events, and the building scheduler has the tools needed to resolve conflicts on the rare occasions they occur. Wards don't have to resolve conflicts, and all can see the events in the building, as I described above.

I have read everything online I could. I get that it's a paradigm shift. You have to realize that people in the stake have always called building schedulers to schedule events but now schedulers can't really help them. They can't schedule anything. With the old calendar system, they could schedule anything. Now each ward must have a scheduler and we have to train 3 times more people on the system (and retrain them much more often because of turnover). So what do building schedulers do now? Reservations are their focus, the documentation says, but that is something done once or twice a year at most when the overall schedule is determined--hardly justification for an entire calling for multiple people. Ward schedulers are the new key to this system, but they are challenged because they cannot see conflicts when they want to use the building until they actually schedule the event. For planning purposes, that is very cumbersome. That's why we had building schedulers in the first place--they were the ones that could see everything going on in a building. Thus we now have a system where people have to use trial and error to schedule soemthing (by creating an event to check for availability, then dealing with a conflict, rather than just looking at a calendar to find a date with no conflict before scheduling).

As for the stake's access, it needs to be for far more than for training. How about events that involve more than one ward but not the whole stake? At the stake level, I can only have an event go to the entire stake. Yes, I get that they can subscribe to the calendars they want, etc. So do we create stake calendars for all possible combinations? Much easier to be able to place an event on the desired ward calendar(s). With this system, we have to rely on the ward doing that--with no idea if it really happened or not. How about scheduling stake events (such as firesides) but wanting to check for ward conflicts before doing so? With this system, that requires an e-mail to each ward and lots of back and forth. Why not give the stake at least read-only access to all ward calendars to make that task super easy? Wards can't even grant read-only access to the stake because the permissions are stuck at the ward level. Calendar info should roll up like financial info from the wards to the stake.

Don't get me wrong--there are some nice improvements with the calendar. But I was anticipating building/room reservations like I enjoy in Outlook now (free/busy search, ability to schedule multiple people/groups/rooms with one event, etc.). That is not what we have. I also did not expect to lose functionality, such as the ability to see calendars for every ward in the stake (which I could do with the old calendar by going to that wards website). We'll come up with workarounds (the best one I heard so far is for the stake to create individual ward calendars at the stake level, then have the ward members subscribe to that calendar), but it's too bad the design didn't take these requirements into account when it was designed. What I requested above solves helps solve those challenges.

davelef wrote:I have read everything online I could. I get that it's a paradigm shift. You have to realize that people in the stake have always called building schedulers to schedule events but now schedulers can't really help them.

It's definitely a paradigm shift, and I fully realize that people used to call building schedulers. I think it's safe to say that every stake that has adopted the new calendar has had to go through this change in philosophy -- our stake certainly did.

davelef wrote:They can't schedule anything. With the old calendar system, they could schedule anything. Now each ward must have a scheduler and we have to train 3 times more people on the system (and retrain them much more often because of turnover).

For the system to work well, each ward should have far more than a single scheduler. The responsibility for scheduling events should be widely distributed. The YW president should add events to the YW calendar, the Ward Mission Leader should add baptismal events, the Primary president should add Primary events, etc. The stake may need to do a bit of initial training of one or more people in the ward, but thereafter, the wards take care of their own training. We've found that the training required for a calendar editor is quite minimal.

The vast majority of the events that get scheduled are created by calendar editors who simply schedule the events. They don't have to call anyone. It greatly simplifies the process.

davelef wrote: So what do building schedulers do now? Reservations are their focus, the documentation says, but that is something done once or twice a year at most when the overall schedule is determined--hardly justification for an entire calling for multiple people.

They do reservations, and they also facilitate conflict resolution. None of our building schedulers have that as their only calling, because it is a very light calling. That's perfectly fine. Again, this is a paradigm shift -- people shouldn't fall into the trap of thinking that building schedulers do the same tasks that they did with the old calendar.

davelef wrote:Ward schedulers are the new key to this system, but they are challenged because they cannot see conflicts when they want to use the building until they actually schedule the event. For planning purposes, that is very cumbersome. That's why we had building schedulers in the first place--they were the ones that could see everything going on in a building. Thus we now have a system where people have to use trial and error to schedule soemthing (by creating an event to check for availability, then dealing with a conflict, rather than just looking at a calendar to find a date with no conflict before scheduling).

I'm sorry if I didn't explain that well enough in my previous post. They most definitely can see all the events scheduled for the building by using the Available Locations check boxes in Week view. Was my explanation not clear, or did you not try that?

davelef wrote:As for the stake's access, it needs to be for far more than for training. How about events that involve more than one ward but not the whole stake? At the stake level, I can only have an event go to the entire stake. Yes, I get that they can subscribe to the calendars they want, etc. So do we create stake calendars for all possible combinations? Much easier to be able to place an event on the desired ward calendar(s). With this system, we have to rely on the ward doing that--with no idea if it really happened or not. How about scheduling stake events (such as firesides) but wanting to check for ward conflicts before doing so? With this system, that requires an e-mail to each ward and lots of back and forth. Why not give the stake at least read-only access to all ward calendars to make that task super easy? Wards can't even grant read-only access to the stake because the permissions are stuck at the ward level. Calendar info should roll up like financial info from the wards to the stake.

You're right -- there are some valid reasons for stake access to ward calendars beyond training. I guess I just don't see those things come up very often. Our stake schedules its entire annual calendar well before the wards do their planning, and wards then schedule around the stake events.

There have been hints from the calendar developers that stake access to ward calendars (at least view capability) will come at some point in the future.

Thank you for your replies. Right now there are only two or three of us that really know much about it all. We have some wards that have nothing in their calendars because they don't understand it. And none of them have ward schedulers. Getting all the wards up to speed to work as you describe feels a bit daunting (not very many even have lds.org logins yet) but we'll do our best to move forward with it.

davelef wrote:And none of them have ward schedulers.

This is a minor point but needs to be made for clarity. The calendar system has no role called ward scheduler. This may be a local calling or assignment. The calendar system currently uses the term calendar editor, or just editor, for those who create and edit events, and building scheduler, someone who by virtue of the role alone cannot create (or schedule) events. It may sound like semantics but the use of the terms adopted for the system helps others understand what the issues are as well as help resolve them.

When speaking of a ward scheduler it is sometimes hard to differentiate whether the reference is to a calendar editor or to a building scheduler. We may make the wrong assumption as to the role being referenced.