Googleカレンダーの権限: the setup order that holds up

Setting up calendar sharing takes about ninety seconds of clicking. The reason it feels like it takes an afternoon is that most people click first and decide afterwards, then adjust, then adjust again, and each adjustment changes what the other person is looking at while they are looking at it.

The order below front-loads the decisions. It costs five minutes at the start and removes almost all of the back and forth afterwards, mostly because it prevents the two configurations that are genuinely painful to unwind: sharing a calendar that holds several unrelated kinds of event, and sharing to individual people for a job that belongs to a role.

Three decisions that belong before the sharing panel

Nothing here requires opening Google Calendar. All three can be settled in a minute.

What is this person actually going to do? There are three answers, and they map to different halves of the permission list. Knowing when the hours are free requires reading only. Understanding what is happening requires reading detail. Rearranging the week requires writing. Requests get phrased as "can you share your calendar", which contains none of this information, so it is worth converting the request into one of the three before touching anything.

Will this person still be doing this job in six months? If the answer is about a named individual who will keep the responsibility, sharing to their address is fine. If the answer is about a role that rotates, an on-call rotation or a scheduling duty passed between assistants, share to a Google group address instead. This single choice determines whether future handovers are a membership change in one place or a sweep through every calendar that was ever shared.

Will this access need to end? If access is temporary, avoid any form of link-based sharing, because links cannot be withdrawn from one holder. Contractors, agencies and trial periods all belong in the sharing list where each entry can be removed on its own.

Decide these three and the configuration becomes a lookup rather than a judgment call. Skip them and the usual outcome is two or three rounds of adjustment, each of which is visible to the other side.

Split the calendars first, then apply the levels

A calendar with one permission setting can express exactly one policy. If a calendar contains client meetings, internal reviews, and blocks of focused work, that single policy has to be wrong for at least two of those three.

Split by how exposed a category of event needs to be, not by who is asking. Three calendars cover nearly every case: one that anyone may see in full, one that colleagues may see in full, and one that stays private. Splitting by person instead produces a new calendar every time a new person appears, which is unsustainable within a year.

Once the split exists, applying permission is mechanical. The open calendar goes out at detail level. The internal calendar goes out at detail level to colleagues only. The private one is either not shared or shared at free/busy, so it contributes hours to availability without contributing information.

There is a per-event alternative, marking individual events private, and it works. It just relies on remembering to set a flag at the moment of creation, every time, forever. Calendar-level separation moves the decision to the point where the event is filed rather than the point where it is typed, which is more reliable in practice. It also survives events created by other people and by automated tools, which will not set the private flag.

The sequence in the interface

With the decisions made, the clicking is short. On a computer, in Google Calendar:

• In the list on the left, hover over the calendar, open the overflow menu, and choose Settings and sharing
• On the left of the settings screen, click Shared with
• Under Shared with, click Add people and groups
• Enter the email address of the person or the Google group
• Choose the access level for that entry from the list
• Click Send

Two of those steps repay attention. The address field accepts a group address exactly as it accepts a personal one, which is where the earlier decision about rotating roles becomes a single character of extra effort rather than a project.

The level list is the other. The top entry, "Make changes and manage sharing", is described by Google as full control of events and tasks with a start and end time, plus the ability to share the calendar with others. That last clause is a transfer of authority rather than an increase in capability. A person who only needs to book and move meetings is fully served by the level below it, and giving them the top one means the sharing list can grow without the owner being involved.

One structural note: to share a calendar somebody else owns, that owner has to have granted the top level first. That is the intended use of it, and about the only one.

Share with a group rather than an individual

The case for group addresses gets stronger the longer a setup runs, and it is worth making concrete.

Consider a support rotation where the duty calendar needs editing access for whoever is on duty. Shared to three individuals, the calendar has three entries, and the next person to join needs a fourth. When somebody leaves, a person who no longer has the duty keeps the access, because removing it is not on anyone's checklist. Shared to one group address, the calendar has one entry that never changes, and access follows group membership automatically.

The saving compounds across calendars. Somebody responsible for eight calendars who shares each to five individuals has forty sharing entries to maintain, and every personnel change touches an unknown subset of them. The same eight calendars shared to groups have eight entries and no personnel work at all.

Offboarding has a second step worth knowing about. If a departing person held the top access level, they may have shared the calendar onward. Removing their entry does not remove whatever they granted. Reading the whole sharing list, rather than searching it for one name, is the only way to notice an entry nobody remembers creating.

When the invitation does not arrive

Adding somebody to the sharing list sends them an email, and an external calendar does not appear in their list until they click the link inside it. This is the single most common reason a correctly configured share appears not to work, and it is invisible from the sending side: the entry looks identical whether or not it was ever accepted.

Google's documented sequence for a missing invitation is worth following in order:

• Confirm the address is correct
• Ask the person to check spam and trash
• Ask the person to search their mail for it
• Remove them from the sharing list, then add them again

The order matters. Re-adding sends a second email, so doing it first usually results in two unread copies of the same message sitting in the same folder the first one was already in. Colleagues inside the same organization skip this entirely, since internal shares appear without acceptance. If an internal share is missing, the cause is the organization's settings rather than the invitation.

A faster way to check what a share actually produced is to keep a second account of one's own in the sharing list. Seeing the result directly beats asking somebody to describe their screen, and it makes the difference between the reading levels obvious in a way the settings text does not.

Reducing access, and the delay before anything shows

Lowering a level is more disruptive than raising one, because it removes something from a screen somebody may be using. Announce it, then change it, then confirm it. If the person had editing access, ask whether they are in the middle of arranging anything before removing it, since a half-finished rearrangement cannot be saved once the ability to write disappears.

Expect a delay before any change is visible, and know which delay applies. A browser reloads and shows the current state almost immediately. A desktop client shows the state as of its last sync, which is why a change can look like it failed for several minutes on a Mac while being perfectly correct on the server. Administrator-side changes are slower again: Google notes these can take up to 24 hours to apply, though they usually take effect much sooner.

This produces a fixed verification order. Check in a browser first. If the browser shows the intended result, the setting is right and the rest is synchronization. If the browser shows something else, the cause is either the setting or an organization-level ceiling above it. Re-editing a setting during the waiting period is how a simple change turns into an afternoon of not knowing which adjustment did what.

Once permission is settled, what remains is the daily cost of using the arrangement: choosing the right calendar each time an event is created, and noticing when two meetings in different places have been booked back to back. The second of those is covered in Travel time, and the overall flow of working across several calendars at once is in the Guide. Questions that come up repeatedly are collected in the FAQ.

Name the calendars so the level is obvious later

A calendar name carries no information about who can see it. Six months after a setup is built, the only way to answer "who can read this one" is to open its sharing screen, one calendar at a time, and the person asking usually gives up before finishing.

The cheap fix is to put the exposure into the name. A prefix is enough: public, team, private. It does not need to be elegant, it needs to be visible in a list that is eight items long. With names like that, a quarterly check of what is shared becomes a matter of noticing that something in the private group has entries in its sharing list, rather than reading every screen to find out.

Colour does the same job in the daily view. Assigning one colour to calendars that can be written to and another to calendars that are read-only removes a small but constant friction: attempting to drag an event that will refuse to move. On a Mac showing several accounts at once, that friction is easy to underestimate, because a read-only event from a colleague's calendar looks exactly like an editable one on a personal calendar. Nothing distinguishes them until the edit is rejected.

Naming also protects the split described earlier. Calendars created without a convention drift back towards a single bucket, because the person filing an event picks whichever name sounds vaguely right. Names that state the exposure make filing a decision about who should see this, which is the decision the split existed to make in the first place.

What to change first

Pick the calendar with the most entries in its sharing list and read the whole list rather than looking for a name. Replace any entry that represents a role rather than a person with a group address, and drop anyone whose real need is availability down to free/busy. That one pass fixes most of what accumulates, and Caltimate handles the part that permission settings never touch, which is how long it takes to put an event in.