Creating, Sharing, and Managing Calendars

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 CDW Amplified for Education’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 (ACL), found in the Calendar’s settings on  


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 the 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 Default settings follow General settings configuration. Discovery is difficult 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 Default settings follow General Settings configuration. Discoverable using the Browse Resource Calendar links. Can be hidden with the 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 into 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.



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.

If you would like assistance with managing your settings or training, book some time in with our support team by reaching out to


Document Version Date Description of Change
1.0 3/18/2024 Updated links away from the AIT legacy site


Articles in this section

See more