Shared calendar not showing in Microsoft 365: the ordered fix path

A shared calendar that never appears in the list. One that shows up but is blank, or only shows blocks of busy time with no detail. A shared mailbox's calendar that worked fine last month and now silently stops updating. These are three of the most common tickets around shared calendars, and while they look like the same complaint, 'it's not working,' they usually have different causes and different fixes.

This guide covers what permission levels actually control, the difference between sharing your own calendar and being granted access to a shared mailbox, why the same calendar can behave differently in a browser than in the desktop app, and an ordered path through the fix, from the checks anyone can do themselves through to the ones that need an administrator.

Two different things get called 'sharing a calendar'

Sharing your own calendar is a personal, self-service action. You choose someone, pick a permission level, and Outlook sends them an invitation to add it. It affects only your calendar, and you can do it without any administrator involvement.

Being granted access to a shared mailbox is a different mechanism. A shared mailbox is its own mailbox with its own calendar, used by a team under one address, and getting into it is a permission grant on the mailbox itself, most often set up by an administrator (or requested through one). Its calendar is not 'your' calendar shared outward; it's a separate calendar you're being let into. The symptoms look identical from the outside, a calendar that won't show up, but the fix for one is a personal resharing action and the fix for the other is checking a mailbox-level permission, so it's worth being clear which one you're actually dealing with before troubleshooting further.

What each permission level actually allows

A calendar that 'won't show anything useful' is very often working exactly as configured, just at a lower permission level than the person expected. It pays to check this before assuming a fault.

• Can view when you're busy: shows only blocks of time as busy or free, with no titles, locations or details at all. This is the level that most often gets reported as 'not showing' when it is technically showing exactly what it was set to show.
• Can view titles and locations: adds the subject and location on top of the busy/free blocks, still without further detail.
• Can view all details: full read-only visibility into events, equivalent to being able to see the calendar as if it were your own, without being able to change anything.
• Can edit: read access plus the ability to create, change or delete entries.
• Delegate: the deepest level, which in addition to editing also routes meeting requests and responses through the delegate on the owner's behalf.

If a calendar appears mostly empty, the first thing to check is which of these levels was actually granted, not whether sharing is broken.

Delegate access vs a simple permission share

A straightforward share, at any of the view or edit levels above, just gives someone a window into the calendar. A delegate is a step further: the owner is naming someone to act for them, and going forward, meeting requests sent to the owner are also routed to the delegate, who can accept or decline on the owner's behalf if that option is enabled. Delegate access can be scoped to the calendar only, or extended further into the owner's mail folders, and it's set up separately from a basic share, not as an extra checkbox on the same screen.

Where this causes confusion: removing someone as a delegate and removing their calendar-viewing permission are two different actions, and doing one without the other leaves a mismatch between what a person can see and what they were meant to be able to do.

Why it works in the browser but not in desktop Outlook

This is one of the most common patterns reported, and it's a genuinely useful diagnostic signal rather than a mystery. Outlook on the web reads permissions from the server on essentially every load, so a newly granted share tends to appear there quickly. Classic Outlook for Windows keeps a local, cached copy of folder and calendar information and doesn't always refresh it immediately, so a permission change can take longer to show up, or can appear to not show up at all until the application is restarted.

There's a second layer to this too: Microsoft has been rolling out changes to how shared calendars behave in the newer, redesigned Outlook experience versus the classic one, and the two don't always match feature for feature. A calendar that displays correctly in one version of Outlook and not another isn't necessarily broken; it may simply be a difference between client versions that hasn't caught up yet on the one behaving oddly.

The practical use of this: if a shared calendar won't show correctly in desktop Outlook, check Outlook on the web before doing anything else. If it looks right there, the problem is very likely local to that desktop client and worth working through the caching-related steps below. If it's wrong there too, it's a permissions problem, not a caching one, and the fix needs to happen at the sharing or mailbox permission level instead.

The ordered fix path

1. 1Confirm what was actually shared, a personal calendar share or access to a shared mailbox, and at what permission level, by checking with whoever granted it. This is something anyone can ask.
2. 2Check Outlook on the web first. If the calendar shows correctly there, the problem is client-side, not a permissions fault; if it's also wrong there, skip ahead to the permission-level checks.
3. 3Confirm the sharing invitation was actually accepted, by searching the inbox for the original invite. If it was declined, deleted, or simply never actioned, ask the owner to resend it rather than troubleshooting further.
4. 4Check that the calendar's checkbox is ticked in the calendar navigation pane, under the relevant calendar group. It's easy for a calendar to be added but not currently selected for display.
5. 5Restart Outlook to force a refresh of cached folder and permission data. If the calendar is still stale after that, remove it from the calendar list and re-add it, which forces a clean resync.
6. 6For a shared mailbox specifically, confirm that Full Access (not just Send As) has actually been granted, since Send As alone does not give calendar visibility, and check whether automapping added the mailbox automatically or whether it needs to be added to Outlook manually.
7. 7If none of the above resolves it, escalate to an administrator to confirm the permission genuinely exists at the mailbox level (not just that an invitation was sent), and to check for any organisation-wide policy affecting how shared calendars behave differently between the classic and newer Outlook experience.

Steps one through five are reasonable for a user to work through alone. Steps six and seven, confirming mailbox-level permissions and checking organisation policy, generally need an administrator, since they involve settings a standard user account can't see or change.