Has anyone else stopped developing Office add-ins because of the insufficient API?

[Kukulkano]

So sad, but we currently stopped any further development for an Outlook add-in. We will see and observe if things get better, but for the moment we have to tell our customers that Microsoft does not provide a stable and sufficient API to realize our add-in for encryption and decryption of messages with our patented technology.

We're missing a lot of API functionality needed to do what we need. It is either not available at all, like to create and fill a new mail item in a specific (sub-)folder without sending and user interaction. Or rebuilding an existing received email. Or trigger sending after rebuilding the message from compose window etc. Or the existing API is not reliable or incomplete, like getAttachmentsAsync with inline images or forwards (see open issues).

Therefore, our customers have to stick with our current Outlook Classic Add-in (COM based, which works fine) or drop our products. Looks like nobody is realizing that Microsoft is currently killing a complete nice industry and also drops a lot of good functionality for their customers. A lot of clever helpers, tools, utilities and third-party integrations will no longer be available within new Outlook. Some people even live from their developed add-Ins and tools. Many of these add-Ins will not even be possible due to the very limited and restricted new API.

Are there others with the same issue? How do you solve the problem? Give up? Found other solutions?

This is what we need and can't find a suitable solution yet:

• Create an additional "send" button near the original send button. In local Outlook it is at least a ribbon bar button, but in the web it only works with the Add-Ins button. This is really hard for users to use. In classic Outlook with our COM add-in they either click the ordinary send button or ours. This makes it easy for them to decide and use the add-in.
• If an encrypted message is in the inbox (or some (sub)folder), we want to either rebuild the message with it's decrpyted content or create some sort of copy in the same (sub)folder with the decrypted content. We found no API suitable to create such copy or rebuild the message.
• If a message is composed and the user wants to send with our encryption, he has to check Add-ins and then our add-in (not intuitive at all). Seems we can open a panel and do our stuff, but getAttachmentsAsync() is unreliable. Not reliable returning inline images and forwarded attachments. This is not acceptable by our customers.
• If a message is composed and the user wants to send with our encryption, we cannot finally trigger sending if we finished conversion (encryption). The user has to click the ordinary send button by himself after starting our attachment from the Add-ins button. This is not intuitive at all.

We found other issues, but not that hard to work around. But the above things seem impossible to solve and are really show-stoppers. This is so sad...

[ykhanapure]

Hi @Kukulkano,

Thank you for sharing your detailed feedback. I wanted to address your concerns regarding encryption and decryption, and provide some updates and guidance on leveraging the existing APIs and launch events for encryption:

1. We acknowledge that Web Add-ins currently lack support for decryption in native Outlook. I'm happy to share that we are actively working on this feature, and we expect decryption support to be available by CY25 Q4.

2. For encryption, you can refer to https://learn.microsoft.com/en-us/office/dev/add-ins/outlook/onmessagesend-onappointmentsend-events?tabs=windows, which outlines how Add-ins can encrypt emails during the onSend event. This should help you address encryption needs for composed messages.

3. We are aware of the current challenges with Attachment APIs. Please rest assured that we are actively working on improving these APIs, and updates are planned as part of our ongoing work this semester.

We appreciate your patience and understanding as we work to address these gaps and enhance the development experience for Add-ins. Please feel free to share further feedback or reach out with any additional questions.

[Kukulkano]

Thank you for your detailed reply, but I'm not asking for built-in enc-/decryption. We like to encrypt and decrypt using our own technology (reliable receipt confirmation, representatives, multi jurisdiction support etc) and for that we need a stable and working API. Currently we open a panel and let users prepare and finally encrypt the message (attachments, body). But then I need to send the message. Instead of simply sending, I can only display a message asking the user to press the send button now. A "send" function is missing.

If a message comes in and is encrypted by our technology, I want to decrypt the attachment and then re-build the message with decrypted content automatically. Looks like it is impossible to manipulate the received message at all. All attachment and body functions seem only available in compose window.

For decryption, I then thought about creating a new email in a "decrypted" sub folder with decrypted content. But it seems impossible to create a new email with own content that is not for sending (not in drafts folder). Also impossible to create a subfolder.

And finally, the above should be automatically and without any user interaction.

In the web mailer, all Add-Ins are hidden behind a small button and it seems impossible to place own buttons. For example, some "send encrypted" button close to the regular send button or some visible "decrypt" button.

Also, the Add-in button in reading mode is directly above the message. The Add-In button during writing is on top in the message ribbon bar. Due to my tests with some people, this was confusing for users not familiar with Add-ins. In fact, no one was able to use the add-in without help. This is the same for other add-ins. Not only my add-in. Add-ins seem not wanted.

For the local legacy Outlook (eg 2024) it seems possible to place buttons in a limited way with the WebExtension style Add-In. For Outlook new, the same restrictions and issues apply as for the web mailer. Our Add-In and it's functionality appears more or less hidden from the user.

For the EWS and Graph-API, I did some research. Some issues might be solved by using them. This is what I found:

• Graph-API will not work for any customer using a local on-prem Exchange server.
• EWS works for local on-prem Exchange servers but will never for some O365 Exchange.
• Office-JS should work in both situations, but all on-prem Exchange servers only support API level 1.5, which is not sufficient at all.
• Office-JS is limited in it's functionality (see all this post above) and not able to replace EWS or Graph-API.

For the moment it looks like using all of the three API together seems key for a somehow always working add-in.

Please tell me that I'm completely wrong with all of this. How can I make this work?

[ykhanapure]

Hi @Kukulkano,

To clarify, we are not developing a built-in Encryption-Decryption feature. Instead, we are building the platform support in Office.js that allows ISVs and Add-in developers to encrypt and decrypt content based on their Add-in functionality. As you mentioned, we are working on enabling a decryption experience that is automatic and requires no user interaction (also referred to as Autorun on the Read surface).

Regarding your question about sending a message from a Taskpane/Panel, this is a feature currently in development and in Preview. It is expected to be available globally by February. Once the documentation is published, I’ll be happy to share it with you. I hope this addresses your concerns around Encryption-Decryption.

As for Add-in buttons in the Read and Compose panes, we are actively working on moving the Apps icon to the ribbon for emails in the reading view. This should resolve the consistency issue you highlighted.

For your queries regarding EWS and Graph API, I will follow up with more detailed information shortly.

[Kukulkano]

we are working on enabling a decryption experience that is automatic and requires no user interaction (also referred to as Autorun on the Read surface).

This sounds promising and would be very welcome! Is there already any documentation available?

Regarding your question about sending a message from a Taskpane/Panel, this is a feature currently in development and in Preview. It is expected to be available globally by February. Once the documentation is published, I’ll be happy to share it with you. I hope this addresses your concerns around Encryption-Decryption.

This sounds also very good. Is it for web access only or also for Outlook new?

As for Add-in buttons in the Read and Compose panes, we are actively working on moving the Apps icon to the ribbon for emails in the reading view. This should resolve the consistency issue you highlighted.

Any enhancement to users using add-ins would be good. But also the ability to place the buttons outside of the add-in dialog (like in Outlook classic and Outlook new) would be useful.

For your queries regarding EWS and Graph API, I will follow up with more detailed information shortly.

Great. I'm looking forward to any further information abozt these APIs. For the moment we focus on Office-JS. But it does not work in OWA for Exchange 2019 and 2016 or on-prem Exchange. I found no overview document explaining all the available APIs and their pros and cons in general, except one from a german website. It took a while to find what I wrote. For the moment, it seems that I need to implement all three APIs in order to create an add-in working with on-prem and o365. Or wait until Office-JS API grows to support all needed cases...

[ykhanapure]

Hi @Kukulkano,

This sounds promising and would be very welcome! Is there already any documentation available?

There is no documentation available at the moment, as this feature is still under development.

This sounds also very good. Is it for web access only or also for Outlook new?

This feature will be available for Classic Outlook, OWA, and the New Outlook. It is currently in preview for Classic Outlook.

Any enhancement to users using add-ins would be good. But also the ability to place the buttons outside of the add-in dialog (like in Outlook classic and Outlook new) would be useful.

Thank you for the feedback. @akshayta23 FYI

Great. I'm looking forward to any further information abozt these APIs. For the moment we focus on Office-JS. But it does not work in OWA for Exchange 2019 and 2016 or on-prem Exchange. I found no overview document explaining all the available APIs and their pros and cons in general, except one from a german website. It took a while to find what I wrote. For the moment, it seems that I need to implement all three APIs in order to create an add-in working with on-prem and o365. Or wait until Office-JS API grows to support all needed cases...

I’ll get back to you with more information on this.