Office Add-ins developer platform community call – August 14, 2024

Office Add-ins developer platform community call – August 14, 2024

Office Add-ins developer platform community call - August 14, 2024

This month’s agenda and presenters

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

  • Install add-ins with Deeplink. Skylar Pan, Senior Program Manager at Microsoft.

  • Equivalent web add-in install on switching to New Outlook for Windows. Akshayta Pulugurtha, Senior Product Manager at Microsoft.

  • Custom function update. Adrian Wu, Senior Product Manager at Microsoft.

  • New timeline for legacy Exchange token deprecation. David Chesnut, Senior Technical Writer at Microsoft.

  • Visual Studio Code extension for Office Add-in update. Mingjia Liu, Product Manager at Microsoft.

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

View video segments

  • Introduction 00:00
  • Install add-ins with Deeplink 00:12
  • Equivalent web add-in install on switching to New Outlook for Windows 02:55
  • Custom function update 12:10
  • New timeline for legacy Exchange token deprecation 19:05
  • Visual Studio Code extension for Office add-in update 27:30
  • Q&A 35:24
  • Resources 37:20

Resources related to this blog’s content

Install add-ins with Deeplink

Equivalent web add-in install on switching to New Outlook for Windows

New timeline for legacy Exchange token deprecation

Q&A (Question & Answers)

We are implementing NAA into our add-in that is reliant on Microsoft Graph calls, with NAA allowing for client-side Graph calls what is the best way for fallback auth? Will we still have to have middle-tier server Graph calls to work with a fallback? We‘re hoping this isn’t the case.

NAA is designed for an SPA Office web add-in, so there is no need for a middle-tier server. MSAL-browser.js (3.15 and later) has a built-in fallback mechanism. If NAA is not detected in the Office host (such as Outlook) MSAL automatically falls back to sign in the user without using NAA. This means SSO will not happen, but the user can still be signed in. We’ll be adding more detail about this to the NAA code samples soon. 

What are the Office version requirements for using NAA?

The Office version requirements for using NAA:

  • Office on Windows: Version 2302 (Build 16130.20306) or later.
  • Office on Mac: Version 16.70 or later.
  • Office on iOS/Android: The latest version available through the app stores.
  • Office on the Web: No specific version requirement; it is supported as long as the web client is up to date.

If you send too many Graph requests, you get sent a 429 response and a header that contains the time you should retry sending the request. If you attempt to make a request during this period, the call is still counted against throttling limits and the retry after gets extended. Though only used in rare situations, consistent calls while throttled will cause the app to get banned from accessing the tenant. However, for SharePoint, all the SharePoint driveItem throttling limits are defined per app per tenant, meaning if calls get throttled they are throttled for all users in a given tenant. The old suggested approach is to use a back off method, where the app sends no requests, until the header retry time, for all users. This was a lot easier when graph requests were made from a server and all graph request traffic was centralized. But having NAA, all the Graph calls are now in separate instances of the app, there is no way to coordinate a back-off method? Just wondering if the new NAA flow can account for this? Or if this is even a problem at all?

Authentication and authorization goes to eSTS service with a login.microsoftonline.com URL. This isn’t a Graph API, so it won’t count towards Graph throttling limits which are different for different APIs see Microsoft Graph service-specific throttling limits.

Call to action

General Resources

Stay connected