Forum Discussion
Accept & Do Not Send a Response
- Jul 25, 2019
What's the status of this change to allow for tracking the response if the user selects "Accept Do Not Send a response"?
Thank you - Jack
Hi all,
Thank you for all your responses and your passion around what the expected behavior is. The Outlook team also agrees with you that "do not send a response" should still update the organizer and just not send an email.
As I'd posted previously, we have fixed this behavior for all Outlook clients except for Outlook for Windows. We know that Windows is our predominant client, and we certainly don't consider ourselves "done" until it's released on Outlook for Windows.
Unfortunately, it's not a simple fix that can be made quickly in the Windows client.
First, I'll explain what we changed that fixed this for the other clients (Mac, Mobile, Web). These clients call modern APIs that go through the Outlook Calendar service before the response status is saved into the attendee's copy of the event on the Exchange store. That service layer contains business logic to handle behaviors like this flow. For any Accept, Tentatively Accept, or Decline commands where the service sees that no response was sent, a server-to-server call is made to the organizer's mailbox to update their tracking list. This S2S call is why the "do not send a response still updates organizer" functionality is only supported when the attendee and the organizer are both in Office 365.
However, the Outlook for Windows client uses a legacy api (MAPI) that saves the response directly into the Exchange store (and does not go through the Outlook Calendar service today). When this happens, the S2S call is not made, so the response status is only saved for the attendee and does not make its way to the organizers tracking list.
The good news is that Outlook for Windows has been working on modernizing the way that they make calendar calls such that they will use the modern Graph APIs to create, update, respond to, and generally manage calendar events. This is not simply changing the call URL path from MAPI to REST. The two APIs are massively different in the ways that they are executed, and requires re-writing the calendar almost from scratch. When Outlook for Windows moves to the Graph APIs, the "do not send a response" behavior will automatically start happening for its users, because now all calendar calls will go through the Outlook Calendar service (and the S2S call will be executed).
The "do not send a response" is not the only benefit users will see with this update. For example, when you change the end date of a recurring series, all the past exceptional instances will be preserved (already supported in the other Outlook clients). Today, with MAPI, the entire series is reset if you just want to shorten or extend it by changing the end date.
I wish I could provide a date for when these changes will be released, but we do not have one. We are actively working on it as our very highest priority for the Outlook Calendar team. As soon as it is released, I will post to this forum.
Please keep comments positive, as well. We all want the same thing here :-). I'm also available on private messages if you want to chat.
Thanks,
Julia
A weekly update on this would be appreciated as it is WAY overdue and clearly everyone wants it now. It should have been completed months ago. You always do the hard tasks first and not the easy ones first which is what you did.