Hi Espo team,
we’re using Google Calendar as part of a CRM-type integration, and we’ve run into a recurring issue with event notifications that would be solved by exposing the existing sendUpdates behavior in the Calendar UI and/or Admin controls. Current situation
When events are created and managed via ESPO CRM Calendar (UI) and/or Google Calendar API, guests receive email notifications whenever an event is updated or deleted – including changes to past events.
From an end-user perspective, this is confusing and noisy. Guests often receive cancellation/update emails for meetings that already happened years or weeks ago, just because someone cleaned up the calendar or synchronized data from the CRM.
With API calls we can control this using the sendUpdates query parameter (for example in the events.delete and events.update methods):
Reference in the official documentation (example for events.delete):
https://developers.google.com/workspace/calendar/api/v3/reference/events/delete
However, this level of control is not available in current UI and not exposed as a policy in Google integration. Problem
It would be extremely helpful to have:
The underlying Google API functionality already exists (sendUpdates), so exposing this in the CRM UI and Admin controls would be a natural and very powerful enhancement.
Thank you for considering this request!
we’re using Google Calendar as part of a CRM-type integration, and we’ve run into a recurring issue with event notifications that would be solved by exposing the existing sendUpdates behavior in the Calendar UI and/or Admin controls. Current situation
When events are created and managed via ESPO CRM Calendar (UI) and/or Google Calendar API, guests receive email notifications whenever an event is updated or deleted – including changes to past events.
From an end-user perspective, this is confusing and noisy. Guests often receive cancellation/update emails for meetings that already happened years or weeks ago, just because someone cleaned up the calendar or synchronized data from the CRM.
With API calls we can control this using the sendUpdates query parameter (for example in the events.delete and events.update methods):
- sendUpdates="all" – send notifications to all guests
- sendUpdates="externalOnly" – send notifications only to external guests
- sendUpdates="none" – do not send any notifications
Reference in the official documentation (example for events.delete):
https://developers.google.com/workspace/calendar/api/v3/reference/events/delete
However, this level of control is not available in current UI and not exposed as a policy in Google integration. Problem
- When our team deletes or modifies historical events (e.g. via a CRM sync or calendar cleanup), guests get unnecessary notifications.
- We would like to avoid sending emails for changes to past events, while still keeping notifications for future events if needed.
It would be extremely helpful to have:
- Per-event notification control in the Calendar UI, based on the existing sendUpdates semantics, for example:
- A dropdown or toggle when editing/deleting an event:
- “Send updates to all guests” (sendUpdates=all)
- “Send updates to external guests only” (sendUpdates=externalOnly)
- “Don’t send updates” (sendUpdates=none)
- A dropdown or toggle when editing/deleting an event:
- Optional Workspace Admin policy, e.g.:
- Default behavior for notifications when editing/deleting past events.
- Ability to set organization-wide default (e.g. sendUpdates=none for changes to past events, sendUpdates=all for future events), with possible overrides at calendar or OU level.
- Reduces “notification fatigue” for our users and customers.
- Prevents confusing messages like “Your event was cancelled” for a meeting that already happened in the past.
- Makes CRM Calendar much more friendly for synchronization scenarios, where large numbers of events may be updated or cleaned up in bulk.
The underlying Google API functionality already exists (sendUpdates), so exposing this in the CRM UI and Admin controls would be a natural and very powerful enhancement.
Thank you for considering this request!
