With the preview release of "the new Outlook" on OWA, Office Add-ins are now buried in the drop down context menu in an email. Additionally, it appears they do not follow the same behavior of Outlook on the desktop, where Office Add-ins will show in the larger ribbon if used more frequently.

According to this article, Office Add-ins can be pinned if they are used frequently:

If you were using add-ins in the classic Outlook on the web experience, they will show up pinned next to mail actions or in the drop-down menu once you open an email in the new experience. You can also install more add-ins from the Office Store—simply open an email, click the drop-down menu, and select Get Add-ins. Once installed, add-ins will show up in the drop-down menu. You can also choose to pin frequently used add-ins.
While I can instruct users to pin this for themselves, it does not appear that Office Add-ins can be pinned by an administrator.

For this feature, it would be great for administrators to be able to customize which add-ins are immediately available to the user by pinning them. Office Add-ins being buried in the menu of OWA is not helpful in this regard.

We use Office.js to build an Outlook web add-in and we make use of the calls composeItem.to.getAsync where the compose Item is Office.context.mailbox.item. The call returns an array of recipients of Office.EmailAddressDetails objects and are as described in this documentation.

In the latest version(s) of Windows Outlook (16.0.11901.20204 and 16.0.11901.20070), we can observe a discrepancy in the resulting EmailAddressDetails.recipientType to the above call when it comes to Dynamic Distribution Groups. We observe that the recipientType used to be distributionList on a slightly older version of Windows Outlook (16.0.11328.20362). But now, the recipientType returns other for Dynamic Distribution Groups. This discrepancy affects clients that are on different Windows Outlook update cycles.

Is this change going to be permanent or will it be using a value something other than other?

This affects how we implement our web add-in because we're concerned with figuring out groups (distribution lists, DDGs, etc.) from users and expanding the groups. As it stands right now, we're unsure whether other is within the category of expandable groups or not as there is no documentation regarding the details of recipientType values.

Ok so I have a Blob file that I'm trying to save on local disk (the Blob is created locally from an ArrayBuffer). The problem I'm facing is that Outlook for macOS does not want to open a FileSaverDialog or something similar to let the user save the file.

My code is working perfectly in Outlook for Web (OWA) on all browsers (including Safari) and Outlook for Windows.

const blob = new Blob([body]); //body is an ArrayBuffer created locally
const link = document.createElement('a');
if (link.download !== undefined) {
const url = URL.createObjectURL(blob);
link.setAttribute('href', url);
link.setAttribute('download', fileName);
link.style.visibility = 'hidden';
document.body.appendChild(link);
link.click();
document.body.removeChild(link);
}

PS: I have tried using window.open(blob);, but Outlook for macOS throws an error in that situation: "There is no application set to open URL blob:https://..."

PS 2: I have also tried using Office.context.ui.displayDialogAsync(url, { height: 100, width: 100, requireHTTPS: true });,but still getting the same error.

How am I supposed to prompt a SaveFileDialog for the user ? Thank you in advance

There was a checkbox in 'the old' OWA which, when checked, ensured that the Compose form (new message, reply, forward) opened in a popup. Please bring that functionality back.

The problem is that my read-pane add-in has a timer which the user can start to record the time spent on writing the reply to a message. I want to record that time in my application. When the compose form opens, the read-pane add-in gets closed and hence we lose the time spent. When the compose form opens in a popup, the read-pane add-in stays in its place and the user can save the time in our application.

NOTE This is impacting our existing customers.

I am unable to unregister a previously registered event handler for ItemChanged event when the handler function is no more available in the page's scope. So there needs to be an ability to either:
- unregister the event handler by name only or
- unregister all the event handlers registered by the add-in

Use Case
My add-in has more than one web-pages and I have a navigation bar in it. So my web-pages unload when I navigate to another page. Because the Office.context.mailbox.removeHandlerAsync function requires the named handler to be a valid function, I can not unregister the handler in another web-page where the user has navigated to. And when I try to register the event handler again (for that web-page), it fails because more than one handlers are not supported.

We have been told that support for add-ins in shared mailboxes will be added to Outlook in Q2/Q3 of 2019. Thus, we have started rolling out support for shared mailboxes in our add-in too.

As part of this, we have noticed that the add-in icons are only rendered in the context of a shared mailbox element if the user is in the _old look_ of Web Outlook.

Since more and more people will be using the _new look_ as default, users should be able to invoke the add-ins via the new look too.

Please add support for rendering the add-in icons in the _new look_ of Web Outlook too in the context of shared mailboxes.

To anyone who wants a temporary work around: it is currently possible to open an add-in a shared mailbox context in the _new look_ by opening the add-in a personal mail box context, pinning it, and then navigating to a shared mailbox item.

I'd like to provide some feedback about Office.EnhancedLocation and Office.LocationIdentifier when developing an Outlook add-in.
First, very happy to see improvements with this!

In my use case, I have an Office Add-in that show me all available meeting rooms (from a different Office 365 tenant). Users can add one or more of those meeting rooms as a location to the invite, through the add-on. Sending the invite, also books the room (and because of an Organization Relationship we can even use the schedule builder to view Free/Busy).
My code would use the EnhancedLocation.addAsync with body:

var locations = [
{
"id": "room1@contoso.com",
"type": Office.MailboxEnums.LocationType.Room
}
];

If room1@contoso.com is a room in our own tenant and exists in our GAL, the location gets updated with the displayName of the room "Room 1 - 6 persons".
If it is a room in the other tenant (and thus doesn't exist in our GAL), it just shows the e-mail address as location.

Preferrably, I would like to do something like:

var locations = [
{
"id": "room1@contoso.com",
"displayName": "Room 1 - 6 persons",
"type": Office.MailboxEnums.LocationType.Room
}
];

With custom locations, they could also use the displayName property and have their own "unique identifier" in the id field. The API would still be consistent.
And with rooms that do exist in the GAL, it could still resolve first with GAL and use the displayName is a fallback mechanism.

Currently, there is an api called 'getTypeAsync' which can get the body type( 'html' or 'text' ). But there is no api to change the body type(for example, the api can be called 'setTypeAsync').

The reason why i need this api is for our customers user exprience. For example, when i use mac outlook client, i can get 'text' type by call 'getTypeAsync'. And i can only set plain text in the body by call 'setAsync'. when i try to set html, it can only return failed. But i think display html will be better for our customers. For example, Our customers can clearly see some hyperlinks, phone numbers, etc. what we want to show them. And can use their mouse to easily access our services without the need to copy plain text hyperlinks or phone numbers.

Actually, i noticed that windows 10 outlook client already implemented. And user can switch menu bar to 'Format Text', and can select paste 'As Html' , 'As plain Text' or 'As Rich Text'. I think maybe, it is only windows outlook client feature without mac.