This may just be a case where I’m unfamiliar with the way Outlook works, but is there a way to delete an Outlook event without sending a bunch of cancellation emails? Does the Microsoft/Outlook Delete Event API have sending a whole bunch of cancellation emails built in as part of its functionality?
I’m asking because our use case involves someone creating a multi-day, multi-event itinerary, and if they were to decide that the published itinerary (for which a calendar is created and attendees have been invited) wasn’t quite ready yet and wanted to unpublish the itinerary (delete the calendar and events), it sends so many cancellation emails. Is this normal?
It seems unnecessarily tedious for the attendees to have to tell their calendar to delete the many events they had been invited to. for Outlook to send a cancellation email for every single event? Is there a way to make the Outlook-to-Outlook experience more seamless and silent like we can with Google-to-Google invitations?
Yeah, what you’re seeing is actually expected behavior with Outlook / Microsoft Graph. When you delete an event where attendees are invited, Outlook treats that as a formal cancellation — and by design, it sends a cancellation email for each event instance. Unfortunately, there isn’t a built-in “silent delete” equivalent to Google Calendar’s more flexible handling.
A couple of things worth noting from my experience:
-
The Delete Event API doesn’t give you a flag to suppress notifications — cancellations are automatically triggered when attendees are present.
-
For recurring or multi-day itineraries, this can definitely get noisy fast since each occurrence can generate its own message.
-
This is especially painful in “draft/unpublish” scenarios like yours, where the intent isn’t really to notify attendees yet.
Workarounds people typically use:
-
Don’t add attendees until the itinerary is finalized (keep it as a draft calendar first).
-
Use a separate “internal” calendar during staging, then create a fresh one when publishing.
-
If you control the flow, you could also consider updating events (e.g., clearing attendees first) before deleting — not perfect, but can reduce notifications in some cases.
Honestly, Outlook just isn’t as seamless as Google Calendar in this specific area.
If Microsoft ever adds a “suppress notifications” flag to the API, that would be a game changer here.
Getting confirmation from someone else that this is just how it works is a relief!
But now that we’ve released the feature to users, I have a new problem. When a new user subscribes to the Outlook calendar after it’s been published, it seems that the Nylas integration is now sending an email update to the organizer every time to update the event. This may be happening in combination with the calendar owner trying to decline some of the events (which Nylas doesn’t know about, so it will send updates to them as if they still want it). (Idk if it’s also sending to all attendees every time as well, or if it’s just the calendar owner.)
Now to reply to your workaround list
- Don’t add attendees until the itinerary is finalized (keep it as a draft calendar first).
Yes, yes 100 times yes. I’ve suggested that we provide the users with a clear warning to let them know that they should only publish the calendar when they are certain it should not update anymore because it generates so many emails. And now with my newly-discovered problem from last week, I’m also going to suggest they push to have all users that want to be subscribed to the calendar get that done beforehand as well.
- Use a separate “internal” calendar during staging, then create a fresh one when publishing.
The “internal”/staging calendar basically sounds like what our users are able to set up in our app, which is the “unpublished” state I’ve been speaking to, so I think this doesn’t fit our situation.
- If you control the flow, you could also consider updating events (e.g., clearing attendees first) before deleting — not perfect, but can reduce notifications in some cases.
I don’t understand how this can generate less emails, so I don’t plan on trying this.
Hello, just wanted to add a couple of things that might help with the new issue you’re seeing:
Organizer getting update emails on every event change: This is because any time you PATCH an event’s attendee list through Microsoft Graph, Outlook treats it as a meaningful update and sends notifications. If you’re adding subscribers one at a time across many events, the organizer gets an email for each one. Try to batch all subscriber additions into a single update per event to minimize the noise.
Declined events getting re-updated: This is most likely a stale data issue. If your app reads the event, then someone declines it in Outlook, and then your app updates that event using the old participant list — it sends the stale RSVP status back to Graph, effectively overwriting the decline and triggering a new notification. The fix is to always fetch the latest event state right before making any update, so you’re working with current RSVP statuses.
On clearing attendees before deleting: This one actually does work — if you PATCH the event to remove all attendees first, then delete it, there’s nobody left to notify on the delete. It’s an extra API call per event, but it does cut the cancellation emails.
The underlying issue is still the same: Microsoft Graph has no notification-suppression option for calendar events. Until Microsoft adds something like that, it’s all about minimizing unnecessary writes and keeping your data fresh before each update.