Outlook Calendar Permissions Not Working: A Read-First Folder Role, Delegate, and Sync Triage

Helpdesk: "Dana gave Chris edit rights to her calendar last week, but Chris still only sees busy blocks. Morgan is Dana's assistant and stopped getting her meeting invites after someone 're-shared' the calendar from PowerShell. Lee can see the team calendar on his PC but not on his phone, and the partner firm says our shared calendar is three hours behind. Can you just remove everyone and share it again?"

Don't wipe and re-share yet. "Outlook calendar permissions not working" is usually one broken layer in a documented folder-permission chain, not a corrupt calendar: the user has no explicit entry and is falling back to Default (usually free/busy only) → they have mailbox Full Access or a group grant but not the calendar role you think → they are an Editor but not a delegate (or the delegate flag was reset) → the grant is right but the recipient's shared-calendar copy is on the old MAPI model, still syncing, or external and syncing on a schedule. Microsoft's calendar and delegate permissions article, the *-MailboxFolderPermission cmdlet references, and the Calendar sharing in Microsoft 365 article are the sources for that chain — not a forum tip that says "remove all permissions and start over."

If the ticket is really a shared mailbox (and its calendar) missing from the Outlook folder pane, start with Shared Mailbox Not Showing in Outlook. If the assistant can manage the calendar but can't send mail as or on behalf of the owner, use Send As Permission Not Working. If Outlook won't load anything because it keeps prompting for a password, use the Outlook password-prompt helpdesk card first. This post covers "the calendar is shared, but the person sees the wrong level of detail, can't edit, doesn't get delegate invites, or sees stale data — and you need a read-first path before you remove and re-share."

TL;DR

• Split the ticket first. Can't open at all ≠ sees only free/busy ≠ can view but not edit ≠ delegate not receiving invites ≠ can't see private items ≠ sees stale or missing events. Each one points at a different layer.
• Read the folder permission, not the mailbox permission. Microsoft: a calendar role grants access only to the calendar folder; Full Access doesn't define the user's calendar role. Run Get-EXOMailboxFolderPermission on owner:\Calendar and read the user's row and the Default row.
• No explicit entry = Default. Default covers authenticated users in your org without their own entry, and is typically AvailabilityOnly (free/busy). "I only see busy blocks" usually means the grant never landed on this user or this calendar.
• Editor ≠ delegate. A delegate is Editor plus SharingPermissionFlags Delegate. Private items need Delegate,CanViewPrivateItems. Using Set-MailboxFolderPermission -SendNotificationToUser without the flags resets them to None, so the person stops being a delegate.
• Check the sharing model before re-sharing. In classic Outlook, Calendar Properties shows "Folder containing Calendar items (REST)" (new model) or (MAPI) (old). Same-tenant changes on the new model sync instantly. Cross-tenant sync runs about every three hours. ICS subscriptions refresh on the recipient service's schedule.
• Remove and re-add the calendar in Outlook, not the permission in Exchange. Microsoft's upgrade path is: delete the shared calendar in Outlook → restart → Add Calendar → Open Shared Calendar. Don't use "Add from address list," which adds it as MAPI.

Where in the chain did it break?

Step 1: Capture the exact symptom (read-only)

Write these facts on the ticket before anyone removes a permission:

Step 2: Confirm the right mailbox and calendar folder (read-only)

Many "permission" tickets are grants on the wrong object.

1. Primary vs secondary. owner:\Calendar is the primary calendar. A secondary calendar the owner created is a subfolder, so owner:\Calendar\Team Rota is a separate permission list. Sharing the primary doesn't share the secondary.
2. Localized folder names. Mailboxes created in another language may not have a folder literally named Calendar. Read the real name before you run anything against :\Calendar.
3. Resource and shared mailboxes. Microsoft documents that users with Full Access to a shared mailbox don't inherit permissions to a room mailbox's calendar. Even when the shared mailbox is the room's resource delegate, users need an explicit calendar entry on the room.

# Read-only (Exchange Online PowerShell)
# Connect-ExchangeOnline   # interactive admin session

# Find the real calendar folder name/path (handles localized mailboxes)
Get-MailboxFolderStatistics -Identity 'dana@contoso.com' -FolderScope Calendar |
  Select-Object Name, FolderPath, FolderType

Step 3: Read the calendar folder permission (read-only)

Microsoft recommends Get-EXOMailboxFolderPermission in Exchange Online PowerShell (it supersedes Get-MailboxFolderPermission there).

# Read-only: the whole permission list for the owner's primary calendar
Get-EXOMailboxFolderPermission -Identity 'dana@contoso.com:\Calendar' |
  Select-Object User, AccessRights, SharingPermissionFlags

# Read-only: just the person in the ticket
Get-EXOMailboxFolderPermission -Identity 'dana@contoso.com:\Calendar' -User 'chris@contoso.com'

How to read it:

Microsoft's simplified permission levels (what users see in updated Outlook clients):

Two documented behaviors that look like bugs:

• Intermediate roles are enforced by the service, not the client. Microsoft: updated clients only know "view" vs "edit." An Author isn't blocked from trying to edit someone else's event; the service rejects the change. Tell users what a custom role can actually do.
• Exchange ActiveSync phone apps treat shared calendars as editable. A read-only recipient may be able to "create" an event that is saved locally and then rejected by the server.

Group grants: -User accepts mail-enabled security groups (including nested ones). Microsoft also notes that calendars can't be shared with Microsoft 365 groups yet, only with individual users or security groups. A user whose access comes from a security group or from Default reads fine, but see Step 6 for why their copy may not upgrade.

Step 4: Mailbox permissions are a different layer (read-only)

Microsoft's calendar and delegate permissions article draws the line clearly:

• A calendar role grants access only to the calendar folder.
• Full Access grants mailbox-level access but doesn't define the user's calendar role.
• Send on behalf is a separate right. Outlook grants it as part of delegate setup, but it can also exist without delegate access.

Microsoft Support adds: granting Full Access doesn't count as sharing the calendar with a delegate.

# Read-only: mailbox-level grants for the same pair
Get-MailboxPermission -Identity 'dana@contoso.com' -User 'chris@contoso.com'
Get-Mailbox -Identity 'dana@contoso.com' | Select-Object GrantSendOnBehalfTo

If Full Access is present and the calendar row isn't, the ticket is in Step 3. Adding more mailbox rights won't fix it. For the Send As / Send on Behalf side, see Send As Permission Not Working. For a recurring audit of who holds Full Access, Send As, and Send on Behalf across shared mailboxes, see the monthly Exchange Online hygiene check.

Step 5: Editor vs delegate, and the flag reset trap (read-only → careful change)

From the Add-MailboxFolderPermission / Set-MailboxFolderPermission references:

The reset trap: Microsoft documents that if you run Set-MailboxFolderPermission with -SendNotificationToUser ($true or $false) and no -SharingPermissionFlags, the flags default to None. An existing delegate becomes a plain Editor and stops receiving invites. That matches "someone re-shared from PowerShell and the assistant stopped getting invites." Running Set- with only -AccessRights Editor (no notification, no flags) keeps the current delegate status.

Two more documented limits:

• Microsoft recommends configuring delegate relationships from Outlook while the calendar owner is signed in. PowerShell is the right tool for folder-permission administration and validation, but not the preferred way to create a complete delegate relationship.
• The "Deliver meeting requests addressed to me and responses to meeting requests where I am the organizer" setting can't be configured in PowerShell (EWS only). Have the owner check it in Outlook's delegate settings.

Known issue worth knowing before you escalate: on the new sharing model, a delegate without CanViewPrivateItems who sends a meeting with a sensitivity label other than Normal (for example Private) sees it appear and then disappear unsent. Microsoft lists it as by design. Either grant private-item access or have the delegate use Normal.

For the best experience, Microsoft advises that only one delegate manage a shared calendar, and that delegates use the Current Channel or Monthly Enterprise Channel of Microsoft 365 Apps.

Step 6: Old vs new sharing model, client, and sync timing (read-only)

Microsoft rebuilt calendar sharing between Exchange Online users. The model decides what the recipient sees and how fast it updates.

Check which one the recipient has:

1. Classic Outlook: right-click the shared calendar → Properties → General tab → Type: Folder containing Calendar items (REST) or (MAPI). Microsoft: this label only appears if the recipient has Editor or Delegate permission.
2. Classic Outlook account setting: File → Account Settings → Account Settings → Change… → More Settings → Advanced → Turn on shared calendar improvements (Exchange Online only). Group Policy REST updates for calendars (RestUpdatesForCalendar = 1 enabled / 0 disabled) locks the checkbox either way. Check that GPO before you tell a user to tick the box.
3. PowerShell: ExtendedFolderFlags shows SharedOut on the owner's calendar and SharedIn on the recipient's copy.

# Read-only: is the share on the new model?
Get-MailboxCalendarFolder -Identity 'dana@contoso.com:\Calendar' | Format-List
# Recipient side: the shared calendar's name as it appears under their Calendar folder
Get-MailboxCalendarFolder -Identity 'chris@contoso.com:\Calendar\Dana Whitfield' | Format-List

Upgrade path (Microsoft Support): this changes the recipient's view, not Exchange permissions. Delete the shared calendar in Outlook → close and restart Outlook → Add Calendar → Open Shared Calendar… → enter the owner. Don't use "Add from address list", which adds it as MAPI. The calendar can look empty for a few minutes, or a few hours for very large calendars, while the first sync runs.

Conditions Microsoft documents:

• The re-open upgrade works only if the user was explicitly granted access. Access via Default (My organization) or a security group won't upgrade their copy.
• Microsoft has been automatically upgrading eligible internal shares (Editor, Delegate, or Full Mailbox Access on primary calendars) since late May 2026 (MC1287370). The rollout is phased, and calendars with a very large number of sharing relationships won't be upgraded.
• EWS clients don't get the improvements. That includes the macOS Calendar app and older Outlook for Mac. On Outlook for Mac, a calendar added through a delegate account stays on the old experience.

Sync timing is documented, not a bug:

Permission changes aren't instant either. If the owner changes permissions in OWA, Outlook mobile, or Outlook for Mac, the recipient's copy re-syncs immediately. From other apps, it re-syncs within the next few hours. When access is removed, Microsoft detects it within a few hours. A same-org recipient drops to the Default level, or the calendar disappears if Default is None. A recipient in another org stops syncing but keeps the stale copy. That's one way to get "they still see it after we removed them."

Step 7: External and cross-premises sharing (read-only)

{% raw %}

# Read-only: which sharing policy applies, and what it allows
Get-Mailbox -Identity 'dana@contoso.com' | Format-List *sharing*
Get-SharingPolicy | Format-List Name, Domains, Enabled

Hybrid sidebar: Microsoft documents that folder permissions cross-forest (on-premises ↔ Exchange Online) work in many scenarios but aren't fully supported. Users can sometimes see only free/busy for a cross-premises calendar despite higher rights, and can't view the calendar of a hidden Exchange Online mailbox. Private items work only when the user is configured correctly as a delegate. Microsoft recommends moving managers and delegates together. Also, the shared calendar improvements don't apply when either person's mailbox is on-premises.

Step 8: Read the known issues and Sync Issues before re-sharing (read-only)

1. In classic Outlook, open the Sync Issues folder. One documented (now fixed) issue logged You do not have sufficient permission to perform this operation on this object for "Can view titles and locations" shares. The workaround: remove the calendar, turn on shared calendar improvements, restart, and re-add it.
2. Read Microsoft's Known issues with classic Outlook Desktop Shared Calendar Improvements page. Current entries include crashes when accepting a share, delegate attachment-update sync errors, Remove Recurrence greyed out on REST calendars (by design), and not being able to add the same shared calendar twice (by design).
3. Compare OWA for the same recipient. If OWA shows the right access, Exchange permissions are fine and the problem is the client or the sharing model (Step 6).

Step 9: Change one thing (only after the read)

After Steps 1–8 agree on the layer:

1. No explicit entry / wrong role: add or set the single entry. Use Add- when there's no row for the user and Set- when there is one. Owners can also do this from Outlook sharing.

   # Change (only after the read): grant view-all-details to one user
   Add-MailboxFolderPermission -Identity 'dana@contoso.com:\Calendar' -User 'lee@contoso.com' -AccessRights Reviewer

   # Change: upgrade an existing entry to Editor WITHOUT touching delegate status
   Set-MailboxFolderPermission -Identity 'dana@contoso.com:\Calendar' -User 'chris@contoso.com' -AccessRights Editor

1. Delegate missing or reset: prefer the owner's Outlook delegate settings. If you use PowerShell, include the flags explicitly. This is Microsoft's own Exchange Online example form.

   # Change: delegate with private items (Exchange Online)
   Set-MailboxFolderPermission -Identity 'dana@contoso.com:\Calendar' -User 'morgan@contoso.com' -AccessRights Editor -SharingPermissionFlags Delegate,CanViewPrivateItems

1. Grant is right, view is wrong: remove and re-open the calendar in Outlook (Open Shared Calendar), not the permission in Exchange.
2. External / policy: adjust the one sharing-policy rule or org calendar setting the error points to.
3. Retest in OWA first, then the affected client. Allow for the documented sync windows before you call it failed.

When a change is justified

FAQ

Why can someone only see free/busy on a calendar I shared with them?
They're probably falling back to Default, which is typically AvailabilityOnly. Or their own entry is AvailabilityOnly / LimitedDetails, or the share landed on a different calendar (primary vs secondary). Run Get-EXOMailboxFolderPermission -Identity owner:\Calendar -User them. In hybrid, cross-premises calendars can also show only free/busy.

Does Full Access give someone calendar permissions?
Not as a calendar role. Microsoft: Full Access grants mailbox-level access but doesn't define the calendar role, and it doesn't count as delegate sharing. Grant the calendar folder role (and delegate flags if needed) explicitly.

Why did the delegate stop receiving meeting invites?
Delegate status is Editor + SharingPermissionFlags Delegate. If someone ran Set-MailboxFolderPermission with -SendNotificationToUser and no flags, the flags reset to None. Re-apply Delegate (preferably from the owner's Outlook delegate settings) and confirm the owner's meeting-request delivery option.

Why can't the delegate see private appointments?
Delegate access doesn't include private items by default. It needs -SharingPermissionFlags Delegate,CanViewPrivateItems on Editor. Without it, a delegate also can't send meetings labeled Private on the new model.

Why does the shared calendar update late or not show on the phone?
Check the model. Old MAPI shares don't sync to Outlook mobile. Re-open with Open Shared Calendar (not "Add from address list") after shared calendar improvements are on. Access via Default or a security group won't upgrade. Cross-tenant sharing syncs about every three hours, and ICS subscriptions refresh on the recipient service's schedule.

Related posts

• Shared Mailbox Not Showing in Outlook (Full Access / automapping — the mailbox layer, not the calendar folder role)
• Send As Permission Not Working (Send on Behalf for delegates vs calendar rights)
• A monthly Exchange Online hygiene check (recurring read-only audit of mailbox permissions)
• Outlook Keeps Asking for My Password — helpdesk card (when Outlook can't load anything, it's auth, not calendar rights)

Free checklist

Calendar-permission tickets often arrive the same week you tighten Conditional Access on Outlook mobile and unmanaged devices. Executives and assistants report "the shared calendar vanished from my phone" and "access blocked" as one outage. Before you enforce, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=outlook-calendar-permissions-not-working

If you want the rest of the M365 admin runway written down for the team (break/fix cards, offboarding and mailbox decisions, and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=outlook-calendar-permissions-not-working

Admin Pack Studio; not affiliated with Microsoft. Steps 1–8 favor read-only checks: Get-EXOMailboxFolderPermission, Get-MailboxFolderStatistics, Get-MailboxPermission, Get-MailboxCalendarFolder, Get-Mailbox / Get-SharingPolicy, Calendar Properties in Outlook, OWA comparison, and the Sync Issues folder. Adding or changing folder permissions, delegate flags, sharing policies, and org calendar settings are deliberate changes. Change one layer at a time, retest in OWA first, allow for the documented sync windows, and check current Microsoft Learn/Support for portal labels and rollout status.