Sharing an Outlook Classic calendar means giving another person permission to view, edit, or manage your schedule from inside their own Outlook profile. You do this from the Home tab of the Classic Outlook desktop client by clicking Share Calendar, picking a recipient, and choosing a permission level such as Can view when I’m busy, Can view all details, or Can edit.
The problem most users run into is that Microsoft has two Outlooks running side by side in 2026, and the steps, menus, and buttons are different in each. Classic Outlook uses the ribbon interface, and its sharing engine runs through Microsoft Exchange permissions, which are governed by your tenant’s external sharing policy in Microsoft 365. If that policy blocks external recipients, your share invite silently fails, and the other person never gets access.
According to Microsoft’s 2025 Work Trend Index, calendar coordination eats 157 hours per worker per year, which is why getting calendar sharing right matters so much.
Here is what you will learn in this guide:
- 📅 The exact click-path to share a Classic Outlook calendar with coworkers, clients, and delegates
- 🔐 How each permission level works and which one to pick for which situation
- 🌍 How to share externally, publish to a URL, and email a snapshot the right way
- 🧑💼 How to set up Delegate Access so an assistant can send meeting invites for you
- ⚠️ The most common mistakes that break calendar sharing and how to fix them fast
Classic Outlook vs. New Outlook: Why the Distinction Matters
Classic Outlook is the long-standing Windows desktop client with the full ribbon, built on MAPI and tightly coupled to Exchange. New Outlook is Microsoft’s rebuilt client that shares a codebase with Outlook on the Web. The two clients handle calendar sharing differently, and a recipient on one version may see different options than a sender on the other.
In Classic Outlook, sharing flows through the Home ribbon and the Folder Permissions dialog. In New Outlook, sharing happens through a modernized side panel that hides the underlying Exchange permission flags. If you or a coworker uses the toggle in the top-right corner to switch between the two, sharing behavior can look inconsistent even though the underlying mailbox is the same.
The why behind this matters. The Classic client exposes the full Exchange folder permission model, which includes roles like Owner, Publishing Editor, Editor, Reviewer, and Contributor. New Outlook surfaces only four friendly options. If you need the Publishing Editor role, for example, so a team lead can create subfolders inside your calendar, you must use Classic Outlook or PowerShell.
The consequence of mixing clients without understanding this split is silent permission drift. A user might set Can edit in New Outlook, switch to Classic, and see the role listed as Editor, which is not identical. A common misconception is that the two labels always map one-to-one, but Publishing Editor in Classic gives the grantee the right to create subfolders, while Editor does not.
Which Outlook Am I Using?
Look at the top-right corner of the Outlook window. If you see a New Outlook toggle that is off, you are in Classic. If the toggle is on and the ribbon is replaced by a slim command bar, you are in New Outlook. You can also check File > Office Account > About Outlook for the version string. Builds earlier than 16.0 are always Classic.
The consequence of misidentifying your client is that you will follow the wrong steps and blame Outlook when the real issue is the client. A real-world example: Jordan, a paralegal, followed a tutorial written for New Outlook while sitting in Classic. He never found the Share Calendar button because he was looking on the wrong ribbon. The fix took ninety seconds once he realized the mismatch.
Account Types That Support Calendar Sharing
Classic Outlook supports full calendar sharing only on Microsoft 365, Exchange Online, and on-premises Exchange Server mailboxes. Outlook.com consumer accounts support a lighter version of sharing through the Microsoft cloud. IMAP and POP accounts do not support calendar sharing at all because those protocols carry only mail, not calendar folders.
The consequence of trying to share from an IMAP account is that the Share Calendar button is grayed out, and users often assume Outlook is broken. A common misconception is that adding a second Exchange account to the same profile will let you share from the IMAP one. It does not. Each mailbox’s sharing ability depends on its own protocol.
How to Share a Classic Outlook Calendar With Someone Inside Your Organization
Internal sharing is the simplest flow because it stays inside your Exchange tenant and does not cross any external boundaries. From the Calendar module in Classic Outlook, click Share Calendar on the Home ribbon, pick the calendar you want to share, type the recipient’s name or email, set a permission level, and click Send. The recipient gets an invite in their inbox and clicks Accept to add the calendar to their view.
Exchange handles the permission change behind the scenes by updating the MailboxFolderPermission object on your Calendar folder. The consequence of skipping the Send step and only setting permissions through Folder Properties is that the recipient never gets an invite and has to add your calendar manually using Add Calendar > From Address Book, which confuses most users.
A real-world example: Maria, an executive assistant at a law firm, needs to see her boss Raj’s schedule. Raj opens Classic Outlook, clicks Share Calendar, types Maria, selects Can view all details, and clicks Send. Maria opens the invite, clicks Accept and View Calendar, and Raj’s calendar appears next to her own in an overlay view.
A common misconception is that sharing a calendar also shares its linked meeting attachments. It does not by default. If Raj attaches a confidential brief to a meeting, Maria will see the meeting but get an access denied error on the file unless Raj also shares the attachment through OneDrive or SharePoint.
Step-by-Step: Internal Share From the Ribbon
Open Classic Outlook and click the Calendar icon in the navigation pane on the left side of the window. On the Home ribbon, click Share Calendar and choose the calendar you want to share from the drop-down. In the sharing dialog, type the recipient’s email address in the To field, and Outlook will auto-complete names from the Global Address List.
Pick a permission level from the drop-down. The five most common choices are Can view when I’m busy, Can view titles and locations, Can view all details, Can edit, and Delegate. Click Send and wait for Outlook to confirm the invite was delivered. The consequence of closing the window without clicking Send is that permissions are written locally but never communicated to the recipient.
Step-by-Step: Internal Share From Folder Properties
Right-click the calendar in the navigation pane and choose Properties. Go to the Permissions tab, click Add, pick the person from the Global Address List, and click OK. Select the new name in the list and pick a permission level, then click Apply. This method is useful for bulk changes because you can add many users in one session.
The consequence of using Folder Properties alone is the same as above. The recipient is not notified, and they must add the calendar manually. A common misconception is that Folder Properties and Share Calendar are redundant. They are not. The first sets permissions, and the second sends an invite. You usually want both.
How to Share a Classic Outlook Calendar With Someone Outside Your Organization
External sharing depends on your tenant admin enabling it in the Microsoft 365 admin center. If the admin has blocked external sharing, the invite will appear to send, but the recipient will get an error when they click Accept. Admins can set organization-wide policies, per-domain allowlists, or per-user exceptions using New-SharingPolicy in Exchange Online PowerShell.
The external share flow is identical to the internal flow with one key difference. When you type a recipient’s email outside your tenant, Outlook routes the invite through the Microsoft cloud and includes a secure link the recipient can open in their own Outlook or in a browser. The consequence of ignoring the external-vs-internal distinction is that external recipients may only see Free/Busy information even if you selected Can view all details, because the default external sharing policy in many tenants caps the detail level.
A real-world example: David, a project manager at a manufacturing firm, needs to share his calendar with a vendor named Priya at another company. David clicks Share Calendar, types Priya’s email, and picks Can view all details. Because the admin set the tenant default to Calendar free/busy information, including time, subject, location, Priya can see more than free/busy but cannot see the body of meetings.
A common misconception is that changing the permission level in the sharing dialog always overrides the tenant policy. It does not. The tenant policy is the ceiling. You can go lower than the ceiling, but not higher, and the consequence of not knowing this is endless back-and-forth with IT when a partner complains they cannot see meeting details.
Verifying the External Share Worked
After sending an external invite, ask the recipient to check their inbox for a message titled [Your Name] has shared their calendar with you. They click Accept and View Calendar, and the calendar opens either in Outlook or in a browser tab on outlook.office.com. If nothing arrives, check your Sent Items for a Non-Delivery Report.
The consequence of not verifying the share is that you may think the recipient has access when they do not. A common misconception is that external shares show up in the recipient’s calendar automatically. They do not. The recipient must actively click Accept before the calendar becomes visible.
Publishing a Classic Outlook Calendar to a URL
Publishing lets anyone with the link subscribe to your calendar as a read-only ICS feed or open a rendered HTML page. You publish from File > Account Settings > Publish This Calendar, which takes you to Outlook on the Web’s publishing page. Pick a calendar, set a permission level, and generate the ICS and HTML URLs.
The ICS URL is a subscription feed. Recipients paste it into their own Outlook, Google Calendar, or Apple Calendar, and their client refreshes the feed every few hours. The HTML URL is a webpage they can bookmark. The consequence of publishing a calendar with Full details is that anyone who gets the URL, forwarded by a third party, can read every meeting subject, location, and body. There is no login gate.
A real-world example: Lena, a yoga studio owner, publishes her class schedule as a Free/Busy calendar so her web designer can embed the HTML URL on the studio’s homepage. Clients see when classes are full without seeing private names. A common misconception is that you can later revoke the URL. You can stop publishing, but any ICS already subscribed on a client may continue to show cached events until that client refreshes.
Choosing the Right Publish Permission
The three publish levels are Availability only, Limited details, and Full details. Availability only shows busy blocks with no titles. Limited details adds meeting subjects but no bodies. Full details shows everything. The consequence of over-sharing at this step is the most common privacy incident in calendar sharing because URL-based feeds cannot be limited to specific recipients.
A common misconception is that a long, randomized URL is private. It is security through obscurity, not real access control. If you email the link, anyone the recipient forwards it to will have the same read access. Treat a publish URL like a public webpage.
Sending a Calendar Snapshot by Email
A calendar snapshot is a static view of your calendar for a date range, sent as an HTML block inside an email with an optional ICS attachment. You create one by clicking E-mail Calendar on the Home ribbon of the Classic Outlook Calendar module. Pick a date range, a detail level, and click OK. Outlook generates the snapshot and opens a new mail message with it embedded.
Snapshots are best when you need to share a specific window, like next week or the project sprint, and you do not want to grant ongoing access. The consequence of using a snapshot when you really need live access is that the recipient sees only what the calendar looked like at the moment you hit send. Any change you make afterward is invisible to them.
A real-world example: Kwame, a consultant, emails a snapshot of his availability for the next ten days to a prospective client so the client can pick an interview slot. A common misconception is that the recipient can reply with a booking and see it land on your calendar. They cannot. Snapshots are one-way, read-only, point-in-time exports.
Delegate Access: Send on Behalf of Someone Else
Delegate Access is the most powerful sharing model in Classic Outlook because it lets another user send and respond to meeting invites on your behalf. You set it up from File > Account Settings > Delegate Access. Click Add, pick the delegate, and choose permission levels for Calendar, Tasks, Inbox, Contacts, and Notes. The delegate model documentation explains the full matrix.
When a delegate creates a meeting in your calendar, the invite goes out with a Sent on behalf of [Your Name] header. Responses from attendees route to the delegate’s inbox, your inbox, or both, depending on the checkbox Delegate receives copies of meeting-related messages sent to me. The consequence of leaving that box unchecked without telling your delegate is that attendee responses only hit your inbox, and the delegate cannot track RSVPs.
A real-world example: Fatima, a chief of staff, is delegate for the CEO’s calendar. She schedules a board meeting, invites twelve directors, and checks the RSVP box so both she and the CEO see the responses. A common misconception is that delegates can read private items by default. They cannot. You must explicitly check Delegate can see my private items in the same dialog, and many companies forbid this for compliance reasons.
Delegate Permission Levels Explained
The four Calendar permission levels for a delegate are None, Reviewer, Author, and Editor. Reviewer can read only. Author can read and create items. Editor can read, create, and modify items, including ones the delegator created. The consequence of assigning Editor to a junior staffer is that they can delete existing meetings, which has caused many embarrassing calendar wipeouts.
A common misconception is that Editor delegate rights and the Can edit share permission are the same. They are not. Editor delegate rights also carry the right to send on behalf of you, while Can edit does not. If you want send-on-behalf, you must use Delegate Access, not regular sharing.
Comparison of Permission Levels in Classic Outlook
Below is a comparison of the permission roles you will see in Classic Outlook’s Folder Permissions tab, based on the Exchange permission role model.
| Permission Role | What the Recipient Can Do |
|---|---|
| Owner | Full control, including the ability to change permissions for others |
| Publishing Editor | Create, read, modify, delete all items and create subfolders |
| Editor | Create, read, modify, and delete all items but not create subfolders |
| Publishing Author | Create and read all items, modify and delete only own items, create subfolders |
| Author | Create and read items, modify and delete only own items |
| Contributor | Create items only, cannot read others’ items |
| Reviewer | Read only |
| Free/Busy time, subject, location | See busy blocks plus subject and location |
| Free/Busy time | See only busy and free blocks, no detail |
| None | No access |
The consequence of picking Owner for a coworker is that they can then re-share your calendar with anyone else, because Owner includes permission to change permissions. A common misconception is that Owner is just a friendlier word for Editor. It is not. Treat Owner as root-level access and use it only for trusted admins or delegates.
Three Common Sharing Scenarios
These three scenarios cover the situations most Classic Outlook users run into. Each table lists a triggering action and the resulting outcome.
Scenario 1: Executive and Assistant
| Sharing Move | Resulting Outcome |
|---|---|
| Executive sets assistant as Editor delegate | Assistant can create, change, and send meeting invites on the executive’s behalf |
| Executive unchecks Delegate receives meeting responses | Only the executive sees RSVPs, assistant cannot track attendance |
| Executive enables Delegate can see my private items | Assistant can read calendar entries marked private, which may break compliance |
Scenario 2: Cross-Company Project
| Sharing Move | Resulting Outcome |
|---|---|
| Project manager sends external share at Can view all details | External partner sees everything the tenant policy allows, often only free/busy |
| Admin raises external sharing policy to full detail for one domain | Partner can then see subjects, locations, and bodies |
| Manager revokes share by removing the name from Folder Permissions | Partner loses access on the next calendar refresh, usually within three hours |
Scenario 3: Small Team Shared Planning Calendar
| Sharing Move | Resulting Outcome |
|---|---|
| Team lead creates a secondary calendar and shares Publishing Editor | Every team member can create, edit, and build subfolders for sub-projects |
| Lead publishes same calendar as HTML Limited details | Clients can view subjects from a webpage without an Outlook account |
| A member accidentally deletes a recurring series | Deletion propagates to every member, lost unless restored from Recover Deleted Items |
Named Real-World Examples
Example 1: Maria the Executive Assistant. Maria supports three partners at her firm. She sets each partner as an Editor delegate on her own calendar so they can book her time, but she keeps them at Reviewer on their own calendars so she cannot accidentally change their meetings. This two-way asymmetric model is a best practice in the Microsoft 365 admin guidance.
Example 2: David the Project Manager. David runs a cross-company product launch. He shares his project calendar with Priya at the vendor using Can view all details, then publishes an HTML view at Limited details that the marketing team can embed in their intranet. He keeps his personal calendar private by using a second calendar folder for project events.
Example 3: Priya the Small Business Owner. Priya owns a bookkeeping firm. She grants her remote assistant Publishing Editor rights so the assistant can create subfolders for each client. She uses Delegate Access to let her CPA send invoices from her inbox without giving calendar editing rights. This separates the two permission flows cleanly.
Mistakes to Avoid
- Assigning Owner to a coworker who only needs to view the calendar, which gives them the ability to re-share your calendar with strangers.
- Skipping the Send step after changing permissions in Folder Properties, which means the recipient never gets an invite and never knows access exists.
- Sharing from an IMAP or POP mailbox, which cannot share calendars at all and will confuse the user with a grayed-out button.
- Publishing a calendar at Full details and emailing the URL, which exposes every meeting to anyone the email is forwarded to.
- Confusing Editor delegate rights with Can edit share rights, since only the first allows send-on-behalf-of.
- Forgetting to check the external sharing policy in the Microsoft 365 admin center, which silently caps external detail levels below what you selected.
- Leaving Delegate can see my private items checked by default, which may violate your company’s compliance rules on privileged communications.
- Relying on calendar snapshots when you actually need live access, since snapshots freeze at send time and never update.
- Deleting a user from the Folder Permissions tab without also unsubscribing any published URLs, since those URLs keep working until you stop publishing.
- Assuming that a long randomized publish URL is secure, when it is really a public link anyone can open.
- Granting Publishing Editor to a junior team member who might create nested subfolders that clutter the main calendar view.
- Sharing a calendar that contains private OneDrive attachments, since the attachments need separate sharing in SharePoint.
Do’s and Don’ts of Classic Outlook Calendar Sharing
Do’s
- Do match the permission level to the recipient’s actual job need, because the principle of least privilege reduces accidental overshares.
- Do verify external shares by asking the recipient to confirm they received the invite, because tenant policies can silently block them.
- Do use Delegate Access for assistants who need to send meetings, because only delegate rights carry send-on-behalf-of authority.
- Do document every external share your team creates in a shared log, because auditors often ask who has access to executive calendars.
- Do revoke access as soon as the working relationship ends, because lingering permissions are a common source of data leaks.
- Do test the recipient’s view from their own client, because what you see as the sender and what they see as the recipient can differ.
Don’ts
- Don’t pick Owner unless you truly trust the grantee with root-level rights, because they can re-share your calendar.
- Don’t publish Full details URLs outside your organization, because the link becomes a public endpoint.
- Don’t assume permissions mirror between Classic Outlook and New Outlook, because the label mapping is close but not identical.
- Don’t rely on snapshots for ongoing coordination, because the recipient only sees a frozen point in time.
- Don’t enable delegate access to private items without reading your compliance policy, because some industries forbid this.
- Don’t share a primary calendar when a secondary calendar would meet the need, because a secondary calendar isolates shared content.
Pros and Cons of Each Sharing Method
Pros
- Internal sharing is fast, auditable, and flows through the Global Address List, which keeps access scoped to known identities.
- External sharing via Microsoft’s cloud is encrypted in transit and requires the recipient to accept, creating a weak audit trail.
- Publishing to a URL lets non-Outlook users subscribe, including Google Calendar and Apple Calendar customers.
- Snapshots give a clean, printable view of a date range without granting persistent access.
- Delegate Access lets an assistant send and respond on your behalf, which is essential for executives.
- Folder Permissions allow granular Exchange roles that New Outlook does not expose.
Cons
- Internal shares do not notify you when the recipient leaves the company, so stale access can persist.
- External shares are capped by tenant policy, which can overrule your chosen detail level without warning.
- Published URLs are public links, so anyone who gets the URL has the access level you published.
- Snapshots freeze at send time and are wrong the moment you change a meeting.
- Delegate Access is easy to misconfigure, especially the private-items and RSVP-routing checkboxes.
- Folder Permissions are hidden deep in the UI, which makes audit and cleanup harder than they should be.
Process and Form Walk-Through: The Share Calendar Dialog
The Share Calendar dialog in Classic Outlook has six fields, and each one matters. The To field accepts email addresses or GAL names. The Subject line is pre-filled as Sharing invitation and usually should not be changed. The Request permission to view recipient’s Calendar checkbox asks for reciprocal access, which is convenient but not required.
The Allow recipient to view your Calendar checkbox must be checked for the share to actually grant access. The Details drop-down sets the level from Availability only up to Full details. The Add this calendar to the list on the server checkbox, when visible, makes the shared calendar appear in Outlook on the Web automatically. The consequence of missing any field is either a failed send or an accidental overshare.
A common misconception is that the Request permission checkbox actually grants you access. It does not. It only sends a request, and the other person must approve it separately. The request-approval flow is documented on Microsoft Support.
Revoking or Changing Permissions
To revoke access, right-click the calendar in the navigation pane, choose Properties, go to the Permissions tab, select the person, and click Remove. To downgrade instead of revoke, keep the person in the list but pick a lower permission level. The change takes effect on the next calendar refresh on the recipient’s client, usually within one to three hours on Microsoft 365.
The consequence of forgetting to remove a departed contractor is that their cached calendar view may continue to work for hours or days until their own tenant syncs. A common misconception is that disabling their Outlook account at their own company revokes your share. It does not. Your permission entry lives on your mailbox, not theirs.
Troubleshooting Common Sharing Failures
When the Share Calendar button is grayed out, the mailbox is usually IMAP or POP, or the profile is still loading. When an external share fails, check the tenant’s sharing policy and any per-user exceptions. When the recipient sees only free/busy despite a higher permission, the tenant’s external policy is capping detail.
When a delegate cannot send on behalf, verify that they are set as Editor delegate and that their Outlook profile is fully synced. When a published URL returns a 404, confirm that publishing is still enabled on the source mailbox. The consequence of skipping these checks is hours of back-and-forth that could be a two-minute fix.
Recap of Relevant Microsoft Guidance
Microsoft’s official guidance is spread across several articles. The primary reference is the share your calendar in Outlook support page. Delegate Access is covered on the allow someone else to manage your mail and calendar page. Admin-side controls are in the sharing policies in Exchange Online documentation.
The consequence of not reading the admin-side guidance as an end user is that you cannot diagnose why your shares behave differently from a coworker’s. A common misconception is that these pages are only for IT. The end-user impact sections are written in plain language and worth the ten-minute read.
FAQs
Can I share my Classic Outlook calendar with a Gmail user?
Yes. You can send an external share to a Gmail address, and the recipient subscribes through Google Calendar using the ICS URL Outlook provides, though detail level depends on your tenant’s sharing policy settings.
Can I share only specific meetings instead of the whole calendar?
No. Classic Outlook shares at the folder level, not the item level, so the workaround is to create a secondary calendar folder, add only the meetings you want to share, and grant access to that folder.
Can a delegate send meeting invites as if they were me?
No. A delegate can send on behalf of you, but not as you, unless the admin grants separate Send As permission in the Exchange admin center, which is a different right from Delegate Access.
Can I revoke a shared calendar remotely from another device?
Yes. Sign in to Outlook on the Web, open calendar sharing settings, remove the recipient, and the change syncs back to Classic Outlook the next time it connects to Exchange.
Can I share a calendar from an IMAP or POP account?
No. IMAP and POP do not carry calendar data, so Classic Outlook disables the Share Calendar button for those accounts and you must move the mailbox to Exchange or Microsoft 365.
Can I see who currently has access to my calendar?
Yes. Right-click the Calendar folder, choose Properties, open the Permissions tab, and every person or group with access is listed there along with their permission level.
Can the recipient re-share my calendar with someone else?
Yes. If you granted them Owner they can re-share, because Owner includes permission to modify permissions, which is why you should pick Editor or lower for most people.
Can I share a calendar without sending an invitation email?
Yes. Set permissions through Folder Properties on the Permissions tab without using Share Calendar, though the recipient must then add your calendar manually from the address book.
Can I publish my calendar so anyone on the internet can see it?
Yes. Use File > Account Settings > Publish This Calendar and select a detail level, but remember the URL is a public link and anyone who gets it has the access level you chose.
Can calendar sharing be blocked by my company?
Yes. Admins can disable external sharing or cap detail levels through Exchange sharing policies, and you cannot override those caps from your own Outlook client regardless of what you select in the dialog.
Can I share my calendar with a distribution list?
Yes. You can add a distribution list on the Permissions tab, and every current member gets the permission level you assign, though new members added later also inherit the access automatically.
Can I recover a calendar entry a delegate accidentally deleted?
Yes. Open the Calendar folder, click Recover Deleted Items on the Folder ribbon, pick the item, and click Restore, as long as the deletion happened inside the tenant’s retention window, usually fourteen to thirty days.