Can a shared calendar belong to the company instead of a person?

Not directly: whoever creates a secondary calendar owns it. Since Google's 5 October 2026 change, deleting or suspending that account deletes or suspends the calendar, so put ownership on an account that will outlive the project and transfer it before any account is removed. An administrator can transfer it from the Admin console with the manage calendars privilege.

Why can nobody book our meeting room?

Almost always the sharing level. A resource shared as free and busy only can be booked only if your organization allows booking resources shared that way; otherwise share it as see all event details, which also means everyone can read the events on it. The booking permission lives in Calendar's general settings in the Admin console.

Do we need an Enterprise plan for team calendars and rooms?

No. Secondary calendars, resources, auto-accept and resource managers are the ordinary Calendar and Admin console features. The automatic release of unused rooms is the one in this article that Google's page lists only for Enterprise Standard and Plus, the Education editions and G Suite Business, checked 12 October 2026.

Shared calendar Google Workspace: setup, rooms, owners

Say an eighteen-person engineering firm. There is one meeting room, one good projector and a van that two crews share. Booking happens in a group chat, which works right up to the morning two people arrive for the same room with clients behind them. Somebody then makes a calendar and shares it with everyone, and the calendar turns out worse than the chat: anybody can delete an entry, nobody knows who put it there, and the van is booked inside an event title that only helps if you think to look.

Google Workspace has two separate answers for this, and the names get swapped constantly. Choosing the right one is most of the work, so that is where we start on a client project.

The two things people call a shared calendar

A secondary calendar is an extra calendar owned by a user: staff holidays, on-call weeks, the publishing plan. People add it beside their own and read it. Whoever creates it owns it, and the policies that apply to that person apply to the calendar.

A Calendar resource is a thing that gets booked rather than a topic: a room, a vehicle, a projector, a hot desk. An administrator creates resources in the Admin console, and they then show up in the event window next to the guest list, where whoever is scheduling can see the room is free and claim it in the same click. Google's answer to "stop double-booking the room" is this one, not a shared calendar, and it is the piece small teams skip most often, because it lives in the Admin console rather than in Calendar.

Most of the mess we get called about is one of these doing the other one's job: a topic calendar used as a booking system, or a room modelled as a user account.

What we check before creating anything

Four answers decide the whole setup, and all four are quicker to read than to undo.

Who will own it. Ownership is now load-bearing, for the reason in the ownership section below. It should sit on an account that will still exist in three years.
The organization's sharing defaults. In the Admin console, Calendar's general settings hold the internal default (no sharing, free and busy only, or all information) and the cap on external sharing. Worth reading before you promise anyone anything: the external sharing option for secondary calendars cannot be set per organizational unit, so it is one answer for the whole organization.
Whether free and busy booking is allowed. This single checkbox under resource booking permissions decides whether a room can hide its event details and still be bookable. Changing it needs the Calendar administrator privilege.
The group that will hold the access. Share the calendar with a group, not with a list of people, for the same reason groups beat named shares everywhere else in Workspace.

Building the team calendar, in order

Create it from the account that should own it. Not whoever happened to think of it, and not a personal account that also holds somebody's private life.
Share it with the group. If only part of the team should see it, put those people in their own group first and share to that.
Choose the permission level on purpose. There are four rungs: see only free and busy, which shows no names and no details; see all event details; make changes to events; and make changes and manage sharing, which is full control plus the right to share the calendar onwards. You need that top level on somebody else's calendar before you can share it at all. Google's labels vary a little between interface versions, the ladder does not.
Know which setting wins. When an organization-wide setting and a person-specific one disagree, the broader permission applies, so a calendar published to the whole organization with full details does not become private again because one person was given free and busy only. Super administrators, and admins with the manage calendars privilege, can see all event details regardless of sharing.
Expect the notification lag. Someone added to the group hears about the calendars shared with it, usually within an hour of joining, and that email is skipped entirely when more than 100 calendars are shared to the group. Tell new hires where the calendar is instead of waiting for Google to.

All of this travels by mail. A calendar shared to a group, an invitation to a client, a decline from a meeting room: every one of them is a message leaving your domain, and if the domain's authentication is incomplete those messages land in spam and the calendar looks broken when it is not. Half a minute on the domain rules that out.

Making the room bookable

Resources are built in a fixed order. Buildings first, because Calendar uses buildings as the foundation for everything else, then features such as a screen, a whiteboard or step-free access, then the resources themselves. Keep each resource name short, around 45 characters is Google's suggestion, because the name people actually see is assembled from building, floor, section, name, capacity and features. A floor has to exist on the building before you can put a resource on it, you need the buildings and resources administrator privilege to create any of this, and a new resource can take up to 24 hours to appear for everyone, though it is usually minutes.

Then two settings decide whether booking works at all.

The sharing level. A resource shared as see all event details can be booked by anyone in the organization, and everyone can also read every event on it, titles and guests included. Shared as free and busy, it keeps those details to itself, but it can only be booked if the organization allows booking resources shared that way. Turning that on is how you get both, and leaving it off is why a free and busy room looks permanently unavailable. A resource with no internal sharing option of its own inherits the organization's default for secondary calendars.
Auto-accept. Set per resource: either accept only invitations that do not conflict, which is what a room normally should do and which also turns away anyone without permission, or add every invitation regardless of conflicts, which is what an approval workflow needs. A recurring series is only accepted when the conflicting occurrences stay under a limit, and Google's pages quote different limits in different versions, so test one real weekly series rather than trusting a number.

When a room has to be requested rather than taken, the boardroom or the van on a Saturday, a super administrator sets up a resource manager: the resource is shared with that person at make changes and manage sharing, auto-accept is set to take every invitation, and from then on they get a new event email and accept or decline on the room's behalf. They do not have to be an administrator. When a room declines, the organizer gets an email and the other guests do not, although the room's status is visible in the event.

Ownership, and the day somebody leaves

This is the part that changed. Google announced on 5 October 2026 that secondary calendars now follow the lifecycle of their owner: delete the owner's account and the calendars they own go with it, suspend the owner and those calendars are suspended too. The rollout started that day for Workspace accounts, described by Google as extended, so a domain may see it arrive over more than a couple of weeks. Before this, an orphaned calendar was handed to somebody who had manage sharing access on it. That safety net is gone.

So ownership is now part of the design, not an accident of who clicked first. An administrator can transfer a secondary calendar from the Admin console, in Calendar's event and secondary calendar management settings, with the manage calendars privilege; an owner can transfer their own from Calendar settings. Transfers stay inside the same domain, and once the account is deleted no transfer is possible at all. Only the owner can delete the calendar, and their access cannot be downgraded while they own it. The offboarding checklist already warned that secondary calendars do not move in the transfer Google offers at deletion time; since 5 October 2026 the price of forgetting is the calendar itself, which is why we now move ownership before anyone touches a user account.

What we watch afterwards

Room insights. Under directory, buildings and resources, room insights, with the Calendar administrator privilege. It answers which rooms are oversubscribed and which are decoration, and it exports to CSV. It only counts structured resources whose category is meeting space and whose time zone is right, data can take at least 24 hours to appear, and past bookings are not recorded.
Automatic release of unused rooms. Calendar can release a room when all but one guest declines, which is genuinely useful. Google's page lists it for Enterprise Standard and Enterprise Plus, the Education editions and G Suite Business, so a team on Business Standard or Business Plus should not plan around it (list checked 12 October 2026). It also skips meetings longer than four hours, rooms that hold twenty or more people, and meetings with external guests.
Calendar's use limits, if anybody scripts this. Creating more than about sixty calendars in a short period, or sharing one calendar to roughly 750 people in a short period, blocks the account from repeating that action for a few hours. Bulk upload is the supported path.
Appointment schedules are a different tool. A booking page for people outside the team is not a room: Business Starter allows a single booking page, Business Standard and Business Plus add multiple schedules, email reminders and availability checked across several calendars, and Frontline and Essentials cannot create them at all (checked 12 October 2026). Modelling client bookings as a resource is a workaround that fails the first time two clients want the same slot.

How Guanacos Tech helps

We set up the calendar side of a Workspace the way we set up groups: ownership on an account that outlives the project, access through groups rather than named people, rooms and vehicles as resources with the sharing level and auto-accept matched to how the team actually books, and an approval path only where the delay earns something. Then we hand over the naming convention and the transfer step, so the day somebody leaves is uneventful. How we work fits on one page. If you would rather have this set up than researched, we are Google Workspace consultants, and half an hour is enough to decide what should be a calendar, what should be a resource, and who should own each one.

Shared calendars that survive: team calendars and bookable rooms in Google Workspace