Sharing Google Calendar across multiple accounts

Most people arrive at this with three accounts already running. A work account issued by an employer, a personal account that has been around since Gmail launched, and a third one attached to a side project or a client. Events accumulate in all three, and the moment someone else needs to see availability, the question turns into a maze of settings pages that all look slightly different.

The steps for sharing are short and well documented. The reason it goes wrong is almost never the steps. It is that the calendar being shared belongs to the wrong account, and that only becomes visible months later, usually on the day an account is closed.

Two problems that wear the same clothes

The first problem is private. Several accounts belong to the same person, and that person wants one screen showing all of them. Nobody else is involved, nothing is being granted to anyone, and the fix is display configuration.

The second problem is public. Another person, a colleague, a partner, an assistant, needs to see or edit something. Access is being granted, it can be misused, and it has to be revocable.

These two get treated as one because Google's interface uses the same sharing panel for both. Adding a personal account's calendar to a work account is done through the same permission dropdown used to give a client visibility. Mechanically that is true. Practically, the second case has consequences the first one does not, and treating them identically is how personal medical appointments end up visible to a whole department.

The useful habit is to decide, before opening any settings page, which of the two is being solved. If the answer is the first, the target is a single view and the permission level barely matters. If the answer is the second, the permission level is the entire decision and the view is incidental.

Ownership decides what survives

Google Calendar has no function for merging two accounts, and no function for transferring ownership of a calendar from one account to another. The calendar belongs to the account that created it, permanently. Everything called sharing is a grant layered on top of that fact.

This turns one question into the most important one on the page: which account should create the calendar in the first place?

The test is to ask what happens when each account disappears. A work account disappears when the job ends, and it takes every calendar it owns with it. A personal account is likely to outlive the arrangement. A calendar built for a project that will outlast an employer therefore belongs in the personal account, shared into the work account, and not the other way around.

The second half of the test is about scope. Sharing a primary calendar means sharing everything in it, forever, including events created three years from now that were never considered when the permission was granted. Creating a dedicated calendar and sharing only that one costs about a minute and keeps the boundary where it was intended. The pattern that works is one calendar per relationship rather than one calendar per person: a calendar for the client, a calendar for the household, a calendar for the team, each owned by the account that should still exist when the relationship ends.

The five levels, and the two that get mixed up

Access to a Google Calendar is granted at one of five levels. The names are unhelpfully similar, and picking the wrong one causes either an awkward conversation or a support ticket.

Level	What the other person sees	What they can do
See only free/busy (hide details)	Busy blocks with no titles	Nothing
See all event details	Titles, times, places, descriptions	Nothing
Make changes to events, seeing private events as free/busy	Everything except events marked private	Create, edit, delete
Make changes and see event details	Everything, plus who else has access	Create, edit, delete
Make changes and manage sharing	Everything	The above, plus granting access to others

The two in the middle are the pair that gets confused, and the difference is worth understanding because it is the only setting that protects individual events. One of them respects the private flag on an event and shows it as a busy block with no detail. The other does not. Someone who marks sensitive appointments as private and then grants the wrong one of these two has quietly removed the protection they thought they had.

The bottom level is the one to be deliberate about. It does not just allow editing, it allows the other person to hand access to a third party. Google is explicit that this is the level required before someone can share a calendar they do not own:

To share a calendar that someone else owns, ask the owner to give you "Make changes and manage sharing" permission. Source: support.google.com

For an assistant who books on someone's behalf, that is exactly the right level. For a colleague who wants to add a recurring meeting, it is more than the situation calls for.

The two view-only levels deserve a note as well, because the lower one is underused. Free and busy hides titles, participants, locations and descriptions, and shows nothing but the shape of a week. For availability questions, which is what most sharing requests actually are, that is the complete answer. The reflex to grant full detail comes from politeness rather than need, and it is the reason so many people can read the subject lines of appointments that were never meant for them. Starting at the lowest level that answers the question, and raising it only when someone asks a question it cannot answer, costs nothing and removes an entire class of later regret.

Levels can also be mixed on one calendar. Different addresses can hold different levels at the same time, so a team calendar can show full detail to three people and busy blocks to twenty. That is usually a better structure than splitting the calendar in two, because a split calendar requires everyone to remember which one to write into.

The account you cannot control

Work and school accounts sit under an administrator, and sharing behaviour there is a policy setting rather than a personal one. Google states it plainly: if the calendar is for work or school, the administrator decides whether it can be shared.

In practice this produces three symptoms, all of which get misdiagnosed as bugs. Sharing to an address outside the organisation silently produces free and busy only, regardless of the level selected. An invitation to an external address never arrives. Or the full detail levels are missing from the dropdown entirely.

None of these can be fixed from the settings page, and none of them are worth spending an afternoon on. The workaround people reach for, forwarding invitation emails to the other account, is worse than the problem, because it creates a copy that stops updating the moment anything changes. The better move is to invert the direction: have the personal account own the shared calendar and grant access to the work account, which is a grant the administrator's outbound policy does not block.

Limits that exist, and where they bite

Google publishes usage limits for Calendar, and they are generous enough that ordinary use never touches them. They matter for one specific situation: setting up sharing for a team in a single afternoon.

The published guidance for Workspace accounts includes not creating more than 60 calendars in a short period and not sharing calendars with many users in a short period, with 750 shares given as the figure. Sending 10,000 invites to people outside the domain in a short period causes external invitations to be throttled, and the Email guests feature is limited to roughly 2,000 emails to external guests.

The number that catches people is the sharing one, because a bulk migration that shares thirty calendars with twenty-five people each crosses it in an afternoon. Throttling is not an error message, it is a silence: shares appear to be saved and the other side never receives anything. Spreading the work across two or three days avoids the whole category. Newer and trial accounts hit tighter versions of these limits than established paid ones, which is why a migration that ran cleanly at a previous employer can stall at a new one on the same steps.

There is a lower and much more common ceiling that is not a limit at all. A person can follow perhaps eight or ten calendars before the display stops being readable, and every additional one after that reduces the value of the whole screen. Sharing twenty calendars into one account is technically fine and practically useless. Deciding who genuinely needs to be visible, rather than who could be, is the step that keeps the result usable.

Sharing an account is not sharing a calendar

The shortcut that seems easiest is handing over the password. It is worth naming why it fails, because it fails in ways that are hard to undo.

Two people signed into the same account are indistinguishable in every log and every event history. Nothing can be attributed, and nothing can be selectively revoked: taking access away means changing the password, which locks out every device and every connected app at once. Two factor authentication makes the arrangement worse rather than better, because the codes go to one phone and the second person is blocked at every new sign-in.

Proper sharing solves all of this. Access is attached to an email address, it can be set at exactly the level required, and it can be removed from one dropdown without disturbing anything else. It costs one extra minute during setup and saves the entire cleanup later.

What the sharing settings do not solve

Once every account is visible in one place and the right people have the right level, a different problem becomes obvious. The screen is now honest, and it shows a week with no space in it. Sharing made the collisions visible. It did not create the gaps that would prevent them.

The gaps are lost at the moment an event is entered, not at the moment it is shared. Travel between two locations, the ten minutes before a call, the wind-down after a hard meeting: none of these arrive automatically, and adding them by hand after the fact almost never happens. What decides whether they exist is how much friction sits between deciding a thing needs time and that time being on the calendar. Holding travel and buffer as part of the event rather than as separate entries is covered in Travel time, and the entry side of the same problem is in Entering events.

What to change first

Before sharing anything, check which account owns the calendar in question, and move the arrangement onto a dedicated calendar owned by the account most likely to still exist in three years. Then pick the permission level from the middle pair deliberately, because that is the one that decides whether private events stay private. If the accounts are settled and the daily view is still the weak part, Compared with other calendars lays out how different apps handle several accounts on one screen.