Can several people edit the same calendar at the same time?

Yes, if each of them has an access level that allows changes. There is no live cursor or locking, so if two people edit the same event within a few seconds, the last write wins. For booking style calendars where collisions matter, it is safer to give people their own colour coded calendars in one shared view than to have everyone typing into a single stream.

What happens to a shared calendar when its owner leaves the company?

The calendar belongs to that account, so it goes wherever the account goes. On a managed Google Workspace domain an administrator can transfer or preserve the data, but on personal accounts there is no transfer path, and guests simply lose access when the account is closed. Creating team calendars under a shared or group account from the start avoids the problem entirely.

Is it possible to share availability without showing what the events are?

Yes. The lowest access level shows only that time is taken, with no names or details. It is the right default for people outside the immediate team, and it can be raised later for anyone who genuinely needs to read the descriptions.

Why can one person edit a shared event while another cannot?

The two people almost certainly have the event through different routes. One has edit access on the calendar itself, the other received an invitation, and a guest can only change their own status, the alerts, the calendar the event appears on and their availability. Checking the access level next to the calendar name in the sidebar usually explains it in a second.

Calendar for multiple users: how to set one up on a Mac

Two or more people need to work from the same schedule. Someone shares a calendar, everyone says thanks, and three weeks later the same three problems appear: a booking nobody can edit, an event that shows up twice, and one person who never gets the alert. The tools are not broken. The setup skipped the part where somebody decided who owns what.

A calendar used by several people is not a bigger version of a personal calendar. It is a small permissions system, and almost every complaint about shared calendars is a permissions question wearing a different hat.

Three different things get called a calendar for multiple users

The first shape is one calendar that several people write to. A studio booking sheet, a family logistics calendar, a duty roster. There is a single stream of events and several hands adding to it. The failure mode is collision: two people book the same slot, or one edits an event the other created and the change is silently lost to a stale view.

The second shape is several personal calendars, overlaid so people can see each other. Nobody writes into anyone else's calendar. They read availability and then send invitations. This is what most workplaces actually run, even when they describe it as a shared calendar. The failure mode here is trust: people stop believing the free space is really free, so they ask in chat anyway and the calendar becomes decoration.

The third shape is a resource. A meeting room, a company car, a piece of equipment. The calendar does not belong to a person at all, and the only interesting question is whether the slot is taken. The failure mode is ownership: the resource lives in someone's personal account, and when that person changes jobs the bookings go with them.

Deciding which shape is being built takes about a minute and saves the argument later. Most groups need two of the three at once, and that is fine, as long as each one is set up as itself instead of as a compromise.

Permission levels are the whole design

Google Calendar exposes five levels when a calendar is shared with a person or a group. The names matter because they map directly onto the arguments people have about privacy.

Access level	What the other person can do
See only free/busy (hide details)	Sees blocks of busy time, no names or details
See event details	Sees names, times, places and descriptions
Make changes (see private events as free/busy)	Edits events that are not marked private
Make changes and see event details	Edits events and sees who else the calendar is shared with
Make changes and manage sharing	Full control, and can share the calendar with other people

The top level is not a convenience upgrade. It hands over the ability to add and remove other people, which is the one action that quietly changes who can read the calendar next month.

If you want to share a calendar that someone else owns, that person must give you the "Make changes and manage sharing" permission. Source: support.google.com

There is one more line worth reading before a work calendar is treated as private. Google's help page notes that an administrator can have special permissions that let them find a calendar and all its event details even when it has not been shared. Anything that genuinely must stay private on a managed account belongs on a separate personal calendar, not on a personal event marked private inside the work one.

Access moves, ownership does not

Sharing a calendar with five people does not create a calendar owned by five people. It creates one owned calendar with five guests. That distinction is invisible while everyone is still employed and painfully visible afterwards.

Two practical consequences follow. The first is that a shared team calendar should be created by an account that will outlive the project. In a small business that usually means a shared account or a group, not the founder's personal address. The second is that the person who owns the calendar controls the invitation list, so if that account is dormant, nobody else can add the new hire.

The same logic applies to individual events. An event has an organiser, and the organiser's copy is the source of truth. Guests can move their own copy around, but a guest cannot reschedule the meeting for everyone. When a booking has to be movable by several people, it should live on a calendar those people can edit, not as an invitation sent from one person's account.

Delegation is the other model, and it is not sharing

macOS Calendar supports a second arrangement for accounts on a CalDAV or Exchange service: delegation, where one person operates another person's calendar account. It is configured in Calendar, under Settings, then Accounts, then Delegation. For a CalDAV account, an Allow Write checkbox decides whether the delegate can edit or only look. For an Exchange account, the level of access is chosen from the Calendars column.

Delegated calendars can be shown inside the main window alongside everything else, or opened in their own window from the Window menu, which is the sane choice when someone manages two or three people's schedules and needs to keep them visually separate.

Delegation also brings the one control that shared calendars lack. On a shared calendar account, an event can be marked with the Private checkbox so that the other people on the account cannot read it. Apple's guide notes the checkbox is missing when the event has attendees or is not on a CalDAV or Exchange server, which is exactly the case where the information has already left the account anyway.

The short version: sharing publishes a calendar to other people, delegation lets other people act as the account. An assistant needs delegation. A team needs sharing. Giving an assistant edit rights on twelve individual calendars is the usual sign that the wrong one was chosen.

The failures that show up in week three

An event cannot be edited. Apple's troubleshooting page lists the reasons in order, and they are worth knowing because the app does not explain itself. Events on a subscribed calendar are read only by definition. A calendar shared with view-only privileges cannot be edited, and the access level can be checked by pointing at the calendar's name in the calendar list. For an event someone was invited to, only a few fields are editable at all: the attendee's own status, the calendar the event appears on, the alerts, and the availability. There is also a quieter cause. If the email address in use is not listed on the Contacts card, the app may refuse to change an event the person created.

The same event appears twice. This is almost always one person being both a guest on an invitation and a viewer of the calendar the event sits on. Nothing is duplicated on the server. Two views of one event are being drawn. Hiding one of the two calendars fixes it and no data is lost.

Alerts land on the wrong machine. On a Mac, default alert settings are chosen per account, and the app ships with no alerts on new events at all. A shared operational calendar that needs a reminder therefore needs one configured, and a personal machine that should stay quiet after hours needs the option that applies default alerts on that computer only.

Times drift for a remote member. Time zone support in macOS Calendar is off until it is switched on in Settings, under Advanced. Until then an event created while travelling can land at the wrong local hour for everyone else.

Seeing several people at once is a separate problem

Granting access solves who may read a calendar. It does not solve how five schedules are read at a glance, and on the desktop that is a real limitation.

A Mac calendar app draws every visible calendar into the same grid. Six people in one week view produces a wall of blocks that is technically complete and practically unreadable. Three habits make it workable.

The first is colour discipline. Colour by person for calendars that belong to people, and by category for calendars that belong to the work. Mixing the two conventions in one window removes the only fast signal the grid has.

The second is using the calendar list as a switch rather than a decoration. Every calendar has a checkbox, and turning off everything except two people converts the wall into a comparison. This is worth practising, because it is the fastest way to answer the question a group actually asks, which is when two specific people are both free.

The third is separating the reading view from the editing view. Day view with a narrow date range shows overlap clearly. Month view shows almost nothing useful once more than two calendars are on, because the blocks stop being positioned by hour.

There is a limit worth naming. macOS Calendar overlays calendars, it does not place people in side by side columns the way a booking system does, and it has no built in view for proposing a slot to people outside the account. Groups that spend real time on that step usually end up adding a scheduling tool next to the calendar rather than replacing the calendar.

Decide these five things before the second person joins

One: name the owner account, and make it one that will still exist next year.

Two: pick the access level per person rather than granting everyone the top level. Most contributors need to make changes and see event details. Very few need to manage sharing.

Three: split calendars by what has to be visible, not by who created them. A calendar is the smallest unit that can be shown, hidden, coloured and shared, so anything that a subgroup should be able to hide belongs on its own calendar.

Four: decide where external invitations come from. If clients receive invitations from three different addresses, the replies scatter and no single account holds the guest list.

Five: agree what a busy block means. A calendar where focused work time is marked busy and a calendar where only meetings are marked busy cannot be read side by side, and mixed conventions are the main reason people stop trusting shared availability. The mechanics of protecting that time are covered in the notes on entering events and travel time.

Change the ownership before the settings

Move the shared calendar onto an account that outlives any one person, then set access per person instead of granting full control to everyone who asks. If viewing several people's schedules on a Mac is the part that hurts, the differences between the desktop clients are laid out in the comparison of calendar apps, and the daily entry side is covered in Caltimate.