Office 365 Outlook connector: Important upcoming changes
The Office 365 Outlook connector is one the most popular connector in Microsoft Flow and PowerApps. It is also one of the most feature-rich connector we have today. We are committed to provide the best experience for end users – and that includes not breaking any flow or app. From time to time though, there are changes on underlying services which necessitate us to push out breaking changes. When we do so, we usually update the versions of the actions and triggers in our connector so that users can start leveraging the new actions and triggers.
We are making a few important updates to the connector as we migrate the underlying API to use the Microsoft Graph API instead of Outlook REST API. These updates will unfortunately force us to deprecate most of the current set of actions and triggers. We will be rolling out these changes over the next couple of months and we strongly encourage all users to start adopting the new actions and triggers.
In this post, you can find the full list of operations that will be deprecated and the new actions and triggers that you can use instead.
Details of the Changes
The following actions will be deprecated soon and will be replaced by the corresponding newer version:
The following list of triggers will be deprecated:
|Current Trigger (to be deprecated)
|When a new email arrives
|When a new email arrives (V2)
|When a new email arrives in a shared mailbox
|When a new email arrives in a shared mailbox (V2)
|When a new event is created (V2)
|When a new event is created (V3)
|See notes below
|When an event is added, updated or deleted
|When an event is added, updated or deleted (V2)
|See notes below
|When an event is modified (V2)
|When an event is modified (V3)
|See notes below
|When an upcoming event is starting soon (V2)
|When an upcoming event is starting soon (V3)
|See notes below
The following existing actions and triggers will continue to work:
- Send approval email
- Send email with options
- When a new email mentioning me arrives (V2)
- When an email is flagged (V2)
Detailed change notes
The main changes between the existing actions and triggers and the new ones are:
- All response properties are now camelCased – in line with the convention for Microsoft Graph
- For Calendar operations and the Set up automatic replies (V2) operation, the TimeZone properties are now separated from the Start and End fields. In general, the properties follow the dateTimeTimeZone resource type.
- The Flag email (V2) operation is enhanced to support set, clear or complete the flag.
- The Mark as read or unread (V2) operation is enhanced to support marking an email as read or unread.
- There is a limit on the message payload of 4MB. For Send an email (V2), in particular, there is a limit of 4MB for the message body and for each of the attachments. Additionally, there is an overall limit of 50MB for a message (which can be reduced by the Admin).
- Some property names have changed. This includes:
- To >> toRecipients
- Cc >> ccRecipients
- Bcc >> bccRecipients
- DateTimeReceived >> receivedDateTime
- DateTimeCreated >> createdDateTime
- DateTimeLastModified >> lastModifiedDateTime
Why the change?
The connector today uses the Outlook REST API, instead of Microsoft Graph API. We are making the move to start using the Microsoft Graph API. In doing so, we are present with 2 sets of challenges:
- Incompatibilities between the Outlook REST API and Microsoft Graph API
- Deprecation of the Outlook REST API v1.0 and the Office Discovery Endpoint API
The Outlook REST API v1.0 and the Office Discovery Endpoint API has been deprecated and is planned to be de-commissioned by November 1, 2019. Today, when a connection is made, we rely on the Office Discover Endpoint API to retrieve the right endpoint for the user’s mailbox. With the migration to Microsoft Graph API, this is handled by the Microsoft Graph API endpoint seamlessly. Before November 1, 2019, we will be rolling out an update to the connector so that we will not be relying on the Office Discovery API. We will be migration the existing connections seamlessly so that it doesn’t break end users.
That said, what really drove us to deprecate the existing set of actions and triggers is really the incompatibilities between the two APIs. We could have tried to provide backward compatible mapping in the connector itself. However, based on our experience, we are usually able to provide the best user experience if we make the connector layer ‘thin’. This allows us to surface almost all functionality provided by the backend service.
To re-iterate, our commitment to provide the best experience for end users remain – and that includes not breaking any flow or app. To that effect, we plan to and will be investing in providing backward compatibility to some of the more popular actions and triggers. However, they will be eventually deprecated and removed. We strongly encourage you to start using the new actions and triggers immediately.