Googleカレンダーの共有: the setup order that holds up

Redoing a calendar share is almost never caused by clicking the wrong button. It is caused by sharing before deciding what the unit of sharing is. A calendar goes to one person, then to a second, then a personal appointment lands on it and the situation changes from a settings problem into an afternoon of moving events between calendars one at a time.

The operation itself is short. What determines whether it holds up is the order the steps are taken in, and specifically whether the unit is settled before anything is granted to anyone. What follows is that order.

The first decision is the unit, not the button

Before opening any sharing dialog there is one thing to settle: for each audience, what should they see. The number of calendars needed equals the number of distinct answers to that.

A team that needs to see meetings, a client who needs to see when a slot is free, a household that needs to see evenings and weekends: three audiences, three different contents, and no single calendar can serve all three. Forcing them onto one calendar means setting it to whatever the strictest audience requires, which leaves every audience with less than they needed.

The count is driven by audience types rather than headcount. A team of ten people who all see the same thing needs one calendar, not ten grants of anything special. Doing this arithmetic on paper first turns everything after it into mechanical work.

Keep the primary calendar out of it

Every Google account starts with one primary calendar named after the address. It is the nearest thing to hand, and it is the wrong thing to share.

The first reason is what lands on it. Every invitation accepted from that address, and every personal entry made in a hurry, arrives on the same calendar with no separation. Sharing it shares all of that.

The second reason is that a primary calendar cannot be deleted or transferred, because it is bound to the account. A calendar created later can be handed over completely, including the right to manage its own sharing, and it can be deleted when the work it existed for ends. A primary calendar offers only one exit, which is to revoke the share.

So the first action, after the decision, is creating a new calendar. Name it for the person receiving it rather than for the person creating it. A private abbreviation makes perfect sense in a settings screen and no sense at all sitting in somebody else's calendar list next to nine others.

Move the events, then grant access

A newly created calendar is empty. If the events that belong on it already exist on the primary calendar, they move first, by opening each event and changing which calendar it belongs to.

Doing this after sharing costs more than doing it before. Every event moved while the calendar is already shared appears and disappears on the recipient's screen, so asking them to confirm what they see produces a different answer each time. Moving first means the confirmation happens once, against a stable state.

Recurring events add one decision. Changing the calendar on a repeating event asks whether the change applies to the series or to a single occurrence, and choosing the single occurrence scatters one meeting across two calendars. The series is the default worth taking, with single occurrences reserved for genuine exceptions.

Start at the lowest access level

Five levels are available, and the useful habit is to begin at the bottom rather than at whatever seems generous.

Situation	Level to start with
Finding a time both parties are free	See only free/busy
Recipient needs to know what the meeting is	See all event details
Recipient schedules on the owner's behalf	Make changes to events
Two people jointly own the calendar	Make changes and manage sharing

For scheduling alone, free/busy is complete. Google's own description of that level is: "People can only find out when you're busy on your calendar." The recipient sees an occupied block and nothing written inside it, which is exactly the information a scheduling decision requires.

One nuance sits between the third and fourth rows. The level that allows changes while showing private events as free/busy is the one that lets somebody schedule on the owner's behalf without reading everything on the calendar, which is usually the right shape for an assistant or a coordinator. The level above it adds visibility of the full detail and of who else holds access, and that difference is worth choosing deliberately rather than landing on by accident.

Moving up happens when someone asks for more, which is a cheap conversation. Starting at the top and discovering later that a recipient could rename events is a more expensive one. "Make changes and manage sharing" in particular grants the ability to bring in other people, and it belongs to calendars that are genuinely co-owned rather than to anyone who might need something eventually.

Share to a group when membership changes

A share can be addressed to an individual or to a group, and turnover is what decides between them.

Where people join and leave, the group is less work. A new arrival added to the group sees the calendar from that moment, and someone removed from the group loses it, with no visit to the calendar's own settings in either case.

Where membership is fixed, individuals are clearer. The sharing screen then lists exactly who has access at what level, which is the thing anyone auditing the calendar wants to read. A group shows as one line, and the actual membership lives somewhere else entirely.

Mixing both on one calendar is the arrangement to avoid. When a person needs to be removed, nothing on the screen indicates which of the two routes granted their access, and the removal that looks successful may not have removed anything.

Verify from the recipient's side

Granting access sends the recipient an email, and Google is explicit that they then have to act on it: "to add your calendar, they need to click the link in the email." Until that happens their calendar list is unchanged.

Nothing on the granting side distinguishes an accepted share from an ignored one. The sharing list shows the name and the level either way. This is why the last step of the procedure is asking, rather than re-reading settings. One sentence to the recipient settles it.

Two things are worth asking at the same time. Which address they are actually signed in with, since plenty of people hold a work account and a personal one and are looking at whichever they used last. And, for anyone outside the organization, whether they see empty blocks rather than nothing at all, because a Workspace administrator can cap what leaves the company and that cap overrides whatever the individual selected.

Decide visibility when creating events, not later

If personal entries are going to live on a shared calendar, the visibility decision belongs at creation time. Each event can be marked private, which leaves the recipient seeing an occupied block without its contents.

Retroactive cleanup does not work at any scale. The number of events only grows, identifying which ones need attention is manual, and the review has to be repeated every time the calendar gains a new viewer. One choice while typing the event costs nothing. A hundred choices in a month's review costs an evening.

Rebuilding when the sharing already exists

Starting from a calendar that was shared in the wrong order is recoverable, and the sequence differs slightly from a clean start.

Create the new calendar, as before. Then move the events across while the old share is still live. Reversing those two steps, by revoking first, leaves the recipient looking at a calendar that has lost its contents for however long the migration takes, and the message about things having disappeared arrives well before the work is finished. Move, then grant access to the new calendar, then revoke the old one. Ordered that way, the recipient never sees a gap.

Meetings organized by other people need separate handling. An invitation that was accepted sits on the account's calendar, but the event itself belongs to the organizer, so moving it to a different calendar changes what the account holder sees and changes nothing for anybody else. The question worth asking is whether the goal is to publish events the account holder organizes, or events the account holder attends. The second case is not a calendar move at all. It is a matter of who appears on the invitation.

After the old share is revoked, one check remains: whether anyone kept a copy by another route. Revoking removes the calendar from a recipient's list, but a subscription created from a secret iCal address was never part of that grant and will keep working.

Stopping a share

Ending a share, when a project finishes or ownership moves, also has an order worth following.

The first step is reading the sharing list rather than acting on it. Anyone who was given the level that includes managing sharing may have granted access to further people, and those names appear on that list without anyone else having approved them.

Then comes the choice between removing individuals and deleting the calendar outright. Deletion removes it from everyone at once, and takes the events with it. Where the events still matter, removing access is the operation to use, and the calendar stays in place with an audience of one.

Settle the Mac side before the calendars pile up

With sharing configured, the remaining work is on screen. Several owned calendars plus several shared ones produce a week view where colour stops carrying meaning.

Two settings are worth deciding early. The first is which calendar new events default to. When that default points at a personal calendar, meetings intended for the team quietly land somewhere nobody else can see, and the resulting report of "the share is not working" has nothing to do with permissions. The second is how fast visibility can be toggled, because the useful pattern is showing team calendars before a meeting and hiding them afterwards, many times a day. That is the part Features is built around, and Compared with other calendars sets out how different applications handle the same overlay.

If the time cost is in creating events rather than reading them, the input path is the thing to change, and Entering events covers that. If the losses come from meetings sitting back to back with no room for the journey between them, Travel time is the relevant piece, and the FAQ covers what usually comes up before any of it is decided.

What to change first

Count the audiences before touching a sharing dialog, and create one calendar per audience rather than per person. Move the events in, grant the lowest level that does the job, then ask the recipient what they actually see.

The part that survives all of this is the screen the calendars land on, which is a tooling question rather than a settings one: see Caltimate.