Googleカレンダーの権限: how to decide what you need

The sharing dialog in Google Calendar presents a dropdown with a handful of options, all named in the same flat register, and the usual method for choosing one is to read the labels and pick something near the middle. That method works often enough that nobody revisits it, which is why the same two levels get granted to almost everybody regardless of what they were asked to do.

A better order is to decide the conditions first and read the labels second. Three questions settle it: who is on the other end, what verb they need, and how long the arrangement lasts. Once those three have answers, the list collapses to one or two viable options. There is also a fourth thing worth checking, which is whether an administrator has already set a ceiling above which nothing chosen here has any effect.

Five levels, and the one in the middle

The first correction is to the count. Google Calendar offers five sharing levels for a person or a group, not four. From lightest to heaviest: see only free/busy with details hidden, see event details, make changes with private events shown as free/busy, make changes and see event details, and make changes and manage sharing.

The third one is the one that gets skipped. Its name is long and its purpose is not obvious from reading it, but it fills a real gap: somebody who needs to edit the calendar without reading everything on it. Google's help text describes what a private event looks like to that person. A private event marked Busy appears as a busy block with no details. A private event marked Free does not appear on the calendar grid at all.

Editing rights and reading rights do not have to be granted together, and that middle level is the only place where they come apart. Anyone choosing between "they need to be able to book meetings" and "but the medical appointments are not their business" has been looking at a list that already contains the answer.

The gap between the top two levels is also narrower than the names suggest. Both create, move, edit and delete events. The higher one adds two things and nothing else: it can add other people to the calendar, and it can open the sharing settings. An assistant who books meetings does not need either.

Name the verb first

The first condition is what the other person is actually going to do, stated as a verb. Vague framings such as "they should be able to see what they need" or "make sure nothing blocks them" push the choice upward every time, because the safest response to an unspecified need is to grant more.

There are three verbs: read, write, and extend. Read maps to the bottom two levels, write to the middle two, extend to the top one. That mapping holds with very few exceptions.

The interesting ambiguity sits inside read. If the question the other person has is "can this hour be booked", free/busy answers it completely. Details become necessary only when the answer changes depending on what kind of event is already there, for instance when a travel block can be moved but a client meeting cannot. That is a legitimate requirement. It is also one that usually goes unstated, which means details get granted to satisfy a need nobody has articulated.

What the person needs to do	The level that covers it
Know which hours are free	See only free/busy
Judge whether an existing block can move	See event details
Create events without reading the private ones	Make changes, private events as free/busy
Create events and check who else has access	Make changes and see event details
Add other people to the calendar	Make changes and manage sharing

There is a further split inside write that removes a lot of unnecessary grants. Creating an event and modifying an existing one are different jobs, and only the second one requires access to this calendar. Anyone who simply needs meetings to exist can create them on their own calendar and add the other party as a guest. The event lands on both calendars, nothing was shared, and no grant has to be revoked afterwards. Calendar access becomes necessary at the point where somebody has to reach into this calendar and change what is already there, which is a much narrower set of people than the set who need to put meetings on it.

The second question is how long

Duration is the condition most often skipped, and skipping it is how calendars accumulate people who left the company two reorganisations ago.

Arrangements come in three shapes. Open ended ones cover colleagues and anyone whose job permanently involves this calendar. Project length ones end on a known date. Single event ones concern one meeting and nothing else.

Calendar level sharing suits the first shape and only the first shape. For the second, somebody has to perform a removal later, and removal is a task with no owner: the person who granted access in week one is rarely the person thinking about access in month six. Recognising this changes the calculation. For a fixed length arrangement, dropping one level is worth doing specifically because of what remains when the removal never happens.

Duration also decides what the grant should be addressed to. A calendar can be shared with an individual address or with a group address, and the difference shows up later rather than immediately. A grant made to a group follows the membership list, so when the person holding a role changes, updating the list is the whole job. A grant made to an individual survives the role change, and removing it depends on somebody remembering that it exists. The trade in the other direction is scope: a group grant widens automatically as the group grows, which is wrong for access that was extended to a specific person for a specific reason. Deciding whether the access belongs to a role or to a person is worth doing before opening the dropdown at all.

For the third shape, the calendar does not need to be shared at all. Adding the person to the event as a guest exposes three independent toggles on the event itself: modify event, invite others, see guest list. The arrangement ends when the meeting ends, and no cleanup task is created.

An administrator may have set the ceiling

On a work or school account, the levels in the dropdown are proposals, not decisions. The organisation's external sharing setting caps what any of them can deliver, and the cap applies to individually shared events too, not only to whole calendars. Google's administrator documentation is explicit that a user cannot exceed the organisation limit when sharing a single event.

The administrator side has four external options: free/busy only, all information with no external editing, all information with external editing, and all information with external management. The last two include the details of events marked private, which is worth knowing before assuming that private means private in every direction.

Two more properties of that setting matter when a choice does not seem to take effect. External and internal sharing are configured separately, and secondary calendars created by users are configured separately again. And changes take up to 24 hours to propagate, though usually less. A level that appears not to work an hour after an administrator changed something has not necessarily been chosen wrongly.

One last point about ceilings: super administrators and administrators holding the calendar management privilege can see all event details on any calendar regardless of how it is shared. Lowering a level restricts colleagues. It does not restrict the organisation.

Calendar level and event level multiply

No single setting decides what a person sees. The calendar level and the per event visibility combine, and the combination is where most of the useful control lives.

Event visibility has three states. Default follows whatever the calendar level says. Public overrides upward, showing full details even on a calendar shared as free/busy only. Private overrides downward, showing a busy block even to somebody who has detail access to the whole calendar.

That third state is what makes it possible to share one calendar with mixed content: work events visible in full, a handful of appointments reduced to busy blocks, no second calendar required. The limits are worth knowing before relying on it. A private event still leaks its start time, its end time, and its creator to anyone invited as a guest or to the calendar of a room that was booked. And a recurring series carries one visibility setting for the whole series, so a single occurrence cannot be made private on its own. An occurrence that genuinely differs has to be detached into a separate event.

There is also a direction of leakage that no calendar level controls. An event with guests lands on their calendars, and whatever those people have shared with third parties determines who else can read it. Booking a room does the same thing through the resource calendar, which is typically visible across the organisation. Lowering a level restricts who can browse this calendar. It does nothing about copies of an event sitting on other calendars with their own sharing settings, so for anything genuinely sensitive the guest list and the room booking are the decisions that matter, not the dropdown.

The practical consequence is that the calendar level should be chosen for the ordinary case, not the exceptional one. Exceptions belong on the events.

Where tasks sit

Tasks follow different rules from events, and assuming otherwise produces choices that do not do what they appear to do.

A task without a start and end time is always private. No sharing level exposes it. A task that does have a start and end time becomes visible to people holding make changes and see event details or higher, and to nobody below that.

This matters for anyone who keeps work in tasks rather than events. A calendar shared at the detail level shows every meeting and none of the task list, which may be exactly right or may be the reason a colleague keeps asking what is being worked on. If the tasks are supposed to be visible, the level has to reach the fourth option, which also grants editing. There is no read only level that includes timed tasks.

What to change first

Pick the level from the three questions rather than from the list: who, which verb, for how long. Anything that survives all three is a defensible grant, and a grant chosen this way rarely needs revisiting.

The part that does need attention afterwards is what a lower level costs day to day. Less access for others means more invitations sent, more availability proposed, more events typed by hand, and a setup that adds friction at the moment of entry gets loosened again within a month. Check how fast an event actually gets created on Entering events, see how multiple calendars sit on one screen in Features, and compare the options in Compared with other calendars. A calendar that is quick to write to is what makes a conservative permission choice survive contact with a busy week, which is the case Caltimate is built around.