post-thumb

Office Add-ins developer platform community call – September 11, 2024

Office Add-ins developer platform community call - September 11

This month’s agenda and presenters

The call was hosted by Mingjia Liu, Product Manager, Microsoft.

  • PowerPoint Preview APIs and Ribbon 1.1 API updates Ester Bergen, Senior Product Manager at Microsoft.

  • Word API updates Yun Wang, Principal Product Manager at Microsoft and Steve Jin, Senior Product Manager at Microsoft.

  • A new NAA sample for Outlook event-based add-ins David Chesnut, Senior Technical Writer at Microsoft.

  • Visual Studio Code extension for Office Add-ins public preview Mingjia Liu, Product Manager2 at Microsoft.

  • WXP Add-ins with the Unified manifest for Microsoft 365 public preview Luyi Han, Senior Product Manager at Microsoft.

  • Q&A. Mingjia Liu, Product Manager, Microsoft.

View video segments

  • Introduction 00:00
  • PowerPoint preview APIs and Ribbon 1.1 API updates 01:27
  • Word API updates 04:56
  • A new NAA sample for Outlook event-based add-ins 12:20
  • Visual Studio Code extension for Office Add-ins public preview 25:05
  • WXP Add-ins with the Unified manifest for Microsoft 365 public preview 27:02
  • Q&A 33:16
  • Resources 39:10

PowerPoint preview APIs and Ribbon 1.1 API updates

WXP Add-ins with the Unified manifest for Microsoft 365 Public Preview

Q&A (Question & Answers)

The OnMessageReadWithCustomHeader and OnMessageReadWithCustomAttachment Events are currently in preview on Classic Outlook (only). Is there a timeline when these Events will be in preview on other platforms? Is the expectation these will be in Requirements Set 1.15, and is that planned for release at this time?

These events on other platforms are already in our backlog and are coming soon. Please stay tuned for the updates.

There’s a common ask from Microsoft on these calls for functionality gaps between Outlook COM add-ins and Office.js. One such gap is that Office.js add-ins don’t support being used from the context-menu but COM add-ins do. I can find prior reference online to this being a requested feature from 2018. Can we get some insight onto if the Office.js team would offer support for making add-ins available in the context menu e.g. when right-clicking an email show configured MessageRead add-ins in the menu.

We don’t have any plans to allow web add-ins to be accessible via a context menu currently but would like to learn more about your scenario. Please leave a message in chat or submit a feature request here.

I’m going to submit my Excel add-in on Partner Center Microsoft 365 and Copilot. I’ve created a related Partner Center SaaS transactable offer under the Commerical Marketplace. The SaaS offer setup has a section that asks do you have published Teams apps, Office Add-ins etc. and if you select the Yes radio button, it asks you to fill in your AppSource link. This page says: “For linked products, search on AppSource will return with one result that includes both SaaS and all linked add-ins. Customer can navigate between the product detail pages of the SaaS offer and linked add-ins. IT admins can review and deploy both the SaaS and linked add-ins within the same process through an integrated and connected experience within the Microsoft 365 admin center.” So my understanding is that as soon as I publish my Excel add-in and its up on AppSource, I just copy that link and put it in my SaaS offer setup and publish it. Then there will be a single AppSource offer for my add-in that will be transactable. Is my understanding correct?

For submission process, see Plan a SaaS offer for the commercial marketplace. If you have additional questions about Publish Center, you can post them in our Microsoft Partner Community​.

I’ve implemented the Microsoft SaaS Accelerator my SaaS transactable offer (which I will link to my Excel Partner Center Add-In offer). This creates a webhook, landing page and admin portal for my SaaS offer, which I have been testing. The admin portal shows me the Purchaser Email and Marketplace Subscription ID. I’ve been working on getting SSO working for my add-in (just starting to test it) which I think is referred to as Authentication. I think I will still need to figure out how to get Authorization working, so only those folks who have purchased the transactable app on AppSource can use it. Can you provide some guidance on how to implement this?

Single Sign-On (SSO) Authentication: Since you’re already working on SSO, you’re setting up a way to authenticate users based on their existing Microsoft identity. This part of the setup confirms the identity of the users. For the official documentation, see Enable single sign-on (SSO) in an Office Add-in.​

Authorization via SaaS Fulfillment APIs: For authorization, you’ll need to check if the user has an active subscription for your SaaS offer after they are authenticated. This involves using the Microsoft SaaS Fulfillment APIs, which allow you to verify subscription status. For more information, see SaaS Fulfillment API.​

When I submit my Excel add-in to the Partner Center it says “Provide any critical testing instructions, including test accounts, license keys and test credentials. Failure to do so results in an automatic rejection .” Once I get Authorization working for my transactable app, is there some sort of a way to provide a back-door so that I can give that info to the Partner Center Certification team?

You can set up a test account and add the necessary information to your critical test instructions. For more information, see the Store step-by-step submission guide.

I have uploaded all of my Excel Add-in dist folder files to my Azure subscription Storage account Blob Container $web folder, which my Manifest points to. Is this the appropriate place to put these files? Should it only contain a subset of the dist folder files? This location does work, but I’m not sure how to secure this location so that someone can’t find this location and take all these files.

Yes, uploading your Excel Add-in distribution files to your Azure subscription’s Storage account Blob Container in the $web folder is an appropriate and common practice. However, there’s no way to prevent from other people getting access as the locations of these manifests are public.

Call to action

General Resources

Stay connected