Google Workspace Calendars have a surprising variety of uses and types. When creating a new Calendar, you should consider the desired ease of discoverability, ultimate use case, and the desire to limit user ability to create new events. Each calendar type has advantages depending on the desired end-user experience. Let’s go through the options around Calendar types and possible use cases.
If you’re sharing a calendar with a Group that changes regularly like your Middle School staff, schools may create a Service Account to hold all Middle School calendars, using the primary calendar as the Main calendar for the school. This makes it easy to add to the calendar list for new members since the “Subscription” of a calendar that’s shared with a group is only announced to the group when the Calendar is first shared. Super Admins can easily manage calendars without needing to log in as the Calendar owner. Using secondary calendars in this way can be problematic. Although users would be permitted to see the calendar, the random nature of the ID would require a programmatic solution (which you can have completed through the use of Amplified IT’s support hours) or requires the subscription link to be posted somewhere for new group members to choose to subscribe to.
Resource Calendars are intended to be a representation of a physical asset’s availability. When working with Resource Calendars, the setting “Browse Resource Calendar links” should generally be set to disallow users from booking resources that are shared as “See only free/busy” as this is the only method to prevent students/non-authorized members from reserving a Resource Calendar. From there, each calendar’s visibility can be controlled through the calendar’s Access Control List, found in the Calendar’s settings on calendar.google.com.
You may find this in-depth article on sharing calendars useful
It can take up to 24 hours for a resource Calendar to be editable by admins within the Calendar Interface. Also be aware that editing the ACL through the Calendar Interface will send an email to all users that the calendar is shared with. This can be muted if shared via API or by blocking messages to the user/group with Content Compliance settings.
There will also be a bit of a learning curve for users when using resource calendars. With these, instead of creating events directly on the Calendar the way you do with both primary and secondary calendars, users would create the event on their own calendar, and invite the resource via the “Rooms” interface.
Admin console settings
Within the Admin console, Calendar settings are primarily in two categories. Settings that apply to a user’s primary calendar found under “Sharing Settings,” and those that apply to all other calendars, including Resource Calendars, under “General Settings.” Settings in each category include default settings (individual calendar ACLs can be changed from the default to something more or less open), max permissions, (users cannot set the external sharing permission for a calendar above what is configured), and settings specific to Primary or Other calendar types, such as use of Meet, or Booking settings for Resource Calendars. Also be aware that where Sharing settings can be configured on a Per OU basis, General settings are configured domain-wide.
Calendar types
Primary Calendar – Primary calendar of a user. Calendar ID is the email address of the user. Discoverability can be hidden by changing the Directory Settings of the User’s account profile. Settings follow the Sharing settings configuration.
Secondary Calendar – Calendar created by a user. Calendar ID is random string @group.calendar.google.com. Default settings follow General settings configuration. Difficult to discover due to the need to have the exact Calendar ID to add to the Calendars list. Create events directly on the Calendar.
Resource Calendar – Calendar owned by the Organization. Calendar ID is random string @resource.calendar.google.com. Default settings follow General Settings configuration. Discoverable using the “Browse Resource Calendar links.” Can be hidden with “Resource booking permissions” setting and Calendar Access Control List. Recommended to “Invite” the resource to events, rather than creating events directly on the calendar.
My calendars vs other calendars
In the Calendar interface, calendars fall in 2 categories. These are separate from the settings category, which can bring some confusion why a calendar would appear under “My calendars” and another calendar will appear under “Other calendars.”
The reasoning a calendar appears under each category has to do with your access to the given calendar. Calendars you have full access to will appear under “My calendars” and those that you are a reader for will appear under “Other calendars.” Super Admins and Admins with the “Calendar” Admin privilege will have Full access to all calendars owned by users within the domain as well as Resource Calendars.
(Calendar Admin Privileges)
Resources
As part of an initiative to categorize calendar utilization, Google introduced Resource categories of Buildings and Rooms. You can associate a Resource calendar with a particular area, or Room. This helps users find resources in their general area, which is especially useful for large districts. When utilized, the default name of a Calendar includes the Building and Room on the Resource in order to organize calendars in a more logical manner for users. When users have visibility of the room, they will appear sorted by building in the “Browse Resource Calendar” menu.
Though these categories are not required, they are recommended for organization purposes. These resource Calendars can now be renamed in the Resource management page of the Admin console, on the details of the resource. Aside from the end user advantage of finding calendars based on Building and having them sorted by Room, Admins get a Utilization Dashboard to see analytics of resource utilization.
You may find this in-depth article on resource calendars useful
If you would like assistance with managing your settings or training, book some time in with our support team by reaching out to support@amplifiedit.com.
Find this article useful? Share it!
-
Stephen Gale
Technical Support Analyst -
About the Author:
Stephen lives in Utah and enjoys the puzzle of investigating users’ problems and finding potential solutions. A recovering/reformed gamer, Stephen throws himself into his passion for staying on top of all things Chrome OS and Chromebook related. Prior to joining Amplified IT, Stephen served as a Network Admin in a Therapeutic Boarding School and an IT director, where he implemented Google Workspace for Education. Stephen has studied computer science and security at Weber State University, Western Governors University. A self-anointed honor, Stephen likes Chromebooks more than almost anyone else in the world.