CloudM Continuity can keep a copy of your users' Microsoft 365 calendars in Google Calendar, alongside their mail. This article is the reference for calendar sync: what you need before you turn it on, how far back and forward it reaches, what is carried across, what is not, and how to check it is working.
Calendar sync is one-way, from Microsoft 365 to Google Calendar, and it is not covered by Recovery Sync. Anything your users change in Google Calendar during an outage stays in Google Calendar. See Recovery and failover below before you rely on it.
What calendar sync does
Calendar sync copies each user's Microsoft 365 calendars and events into their Google Workspace account. Microsoft 365 is the source of truth: changes made in Outlook flow to Google Calendar on the policy's sync schedule, and nothing flows back.
Because the sync only runs in one direction, edits made in Google Calendar to an event that came from Microsoft 365 may be overwritten the next time that event is synced. Treat the Google copy as read-only for synced events.
Like mail, calendar sync has two phases. The first time a user's calendar is synced, everything inside the sync window is copied. After that, delta syncs pick up new, changed and deleted items on the schedule set in the policy. Each enabled item type has its own sync frequency in the policy, so you can sync calendars more or less often than mail within the limits of your licence tier.
Before you start
Calendar sync needs three things in place before you can enable it on a policy.
Calendar in your licence
Calendar is a licensed service, separate from mail. If it is not in your licence, the Calendar item type on the policy form is disabled and the Connections page shows Calendar as Not licensed. You can check which services you have under Licensed services on the Settings page. Contact CloudM or your partner to add Calendar to your licence.
Microsoft 365 permission
Your Microsoft 365 app registration needs the Calendars.Read application permission, with admin consent granted. If you set up Continuity before calendar sync was available, this permission will not be on your app registration yet. Add it, grant consent, then test the connection. See Connecting Microsoft 365.
Google Workspace API and scope
In Google Workspace you need to:
- Enable the Google Calendar API in the Google Cloud project used by your Continuity connection.
- Add the domain-wide delegation scope
https://www.googleapis.com/auth/calendarto the client ID used by your Continuity connection, alongside the existing scopes.
Again, existing customers will need to add both. See Connecting Google Workspace.
Enable Calendar on the policy
Once the permissions are in place and Calendar is in your licence, tick the Calendar item type on the sync policy and set its sync frequency. Users matched by that policy will have their calendars synced from the next cycle. See Creating a Sync Policy.
On the Connections page, each service shows Connected or Not licensed for both your Microsoft 365 and Google Workspace connections. Check the Calendar row shows Connected on both before you enable it on a policy.
The sync window
Calendar sync covers events from 18 months in the past to 18 months in the future. The window moves forward with time and its size cannot be changed.
In practice this means:
- Events older than 18 months are not synced. Events more than 18 months in the future are not synced yet.
- Events that have already been synced stay in Google Calendar. They are not removed when they become older than 18 months.
- Events more than 18 months ahead appear in Google Calendar as the window moves forward and brings them into range.
- If a synced event is rescheduled to a date outside the window, it is removed from Google Calendar. The original stays in Microsoft 365.
If a user notices that a far-future event is not in Google Calendar yet, this window is the reason.
What is synced
Calendars
When a calendar is deleted in Microsoft 365, the Google calendar it was matched to is deleted as well. This includes a Google calendar that already existed and was matched by name, together with any events that were created directly in Google Calendar on it. Before you enable calendar sync, check whether any of your users have Google calendars with the same name as a Microsoft 365 calendar, and decide whether you want them linked.
| Microsoft 365 calendar | What happens in Google Calendar |
|---|---|
| Default calendar | Events are merged into the user's primary Google calendar. The primary calendar is never renamed. |
| Secondary calendar with the same name as an existing Google calendar | The existing Google calendar is reused. The match is on the exact name. |
| Secondary calendar with no matching Google calendar | A new Google calendar is created with the same name and time zone. |
| Calendar renamed in Microsoft 365 | The matched Google calendar is renamed to match. |
| Calendar deleted in Microsoft 365 | The matched Google calendar is deleted, including any events on it. See the note above. |
| Holiday, birthday, read-only and subscribed calendars | Skipped. These are not synced. |
Sharing
Calendar sharing permissions set in Microsoft 365 are translated to Google Calendar access roles, and kept in sync when they change.
| Microsoft 365 permission | Google Calendar role |
|---|---|
| Free/busy only | Free/busy reader (can see when the user is busy, not event details) |
| Read, Limited read or Custom | Reader (can see event details) |
| Write or Editor | Writer (can change events) |
Permissions granted to people who do not have a Google account in your destination domain are skipped. Sharing changes do not trigger Google's sharing notification emails.
Events
| Event detail | How it appears in Google Calendar |
|---|---|
| Subject, start and end time, location | Carried across as they are. |
| All-day events | Synced as all-day events. |
| Body | Carried across as plain text. HTML formatting is removed. |
| Show as | Free shows as Free in Google Calendar. All other values show as Busy. |
| Sensitivity | Private and Confidential events are marked Private in Google Calendar. |
| Categories | Approximated to one of Google Calendar's event colours. |
| Recurring series | Synced as a series, including modified, moved and cancelled occurrences, "this and following" changes that split a series, and all-day exceptions. |
| Teams meeting link | Kept as text in the event description. No Google Meet link is created. |
Attendees
| Attendee detail | How it appears in Google Calendar |
|---|---|
| Internal attendees | Mapped to their Google Workspace address where one exists. Otherwise kept with their original address. |
| External attendees | Kept as real attendees on the event, with their responses. |
| Responses | Accepted, declined, tentative and no response are preserved. |
| Display names, required or optional | Not carried. Attendees appear by address only, and the required/optional distinction is dropped. |
Notifications
Calendar sync never sends email. Creating, updating or deleting an event in Google Calendar as part of a sync, whether the first sync or an ongoing one, does not send an invitation, update or cancellation to any attendee, internal or external. Sharing changes do not send notification emails either. Your users' contacts will not know a sync has happened.
What is not carried
- Reminders. Calendar-level default reminders are not transferred, and per-event reminders are replaced by the Google calendar's default reminder.
- Attachments on events.
- Calendar colour.
- Formatting in the event body. The text is kept, the formatting is not.
- Attendee display names and the required/optional distinction.
- Teams meeting links are not converted to Google Meet links. The link is kept as text.
- Guest permissions are set the same way on every synced event and are not taken from Microsoft 365: guests can invite others and see the guest list, but cannot modify the event.
Recovery and failover
Recovery Sync covers mail only. Calendar data synced to Google Calendar is not returned to Microsoft 365, and changes your users make in Google Calendar during an outage are not synced back.
During a Microsoft 365 outage, your users can see their synced calendars in Google Calendar and work from them. Anything they create or change there during the outage stays in Google Calendar. When Microsoft 365 is back, those changes are not recovered, so anyone who needs them in Microsoft 365 will need to recreate them there. Edits made in Google Calendar to events that came from Microsoft 365 may also be overwritten once sync resumes.
For how recovery works for mail, see Understanding Recovery Sync.
Monitoring
Calendar sync is tracked per user on the Sync Status page. Open a user's detail panel and the sync history shows a separate entry for each service enabled on their policy: Email and Calendar. For Calendar, each entry shows counts across the user's calendars and events:
- Processed: items created, updated or renamed
- Removed: items deleted
- Errors: items that failed
Calendar sync does not keep a record of each individual item, so there is no list of failed calendar items and no per-item retry. The View errors list and Retry in the detail panel apply to mail only. Sharing permissions and attendees that fail to sync are retried automatically on later cycles. If the Errors count for Calendar persists across several cycles, check that Calendar shows Connected on both connections and that the permissions above are in place.
If Calendar is enabled but no calendar sync has run for the user yet, the panel shows "No calendar sync history available for this profile."
See Viewing User Sync Details for the rest of the detail panel.