Building an MS Outlook Add-In: Part Three –  Testing and Approval

Once your add-in is ready to go, you need to know how to handle any errors, test for reliable performance and prepare for deployment. 

This is the third of a three-part series where we’re aiming to be able to save an email (as an EML file) from a user’s inbox into a CRM system an Outlook add-in; you can find parts one and two below.

In this part, we’re looking at working with the Graph API, accessing your email content and connecting with your CRM.

Handle Errors and Provide User Feedback

Implement error handling to manage potential issues during API calls. Provide clear and user-friendly feedback within the add-in interface to inform users about the success or failure of the operation.

Here are a couple of tips and guidelines:

First of all, use the Yeoman generator. It has sample code built-in to handle all of your authentication scenarios. The code is tricky to follow, but it works!

Second, most of your Graph API-related problems are related to expired access_tokens and refresh_tokens. Getting the user to log out and in again solves most of your problems.

Testing and Deployment

Thoroughly test the add-in in different scenarios to ensure it performs reliably. Debug any issues that arise during testing. Once confident in the add-in’s functionality, deploy it to the intended users through the Microsoft Office Store or internal distribution methods.

Testing Outlook add-ins is complex due to the various server and client platforms. You should note that the Graph API is only supported on Outlook.com and Microsoft 365. You cannot use it with Gmail (which isn’t supported for add-ins anyway) or Exchange On-Premise.

A typical Outlook add-in will support the following clients:

  • Outlook 2016 or later on Windows
  • Outlook 2019 or later on Windows
  • Outlook 2013 or later on Mac
  • Outlook 2016 or later on Mac
  • Outlook 2019 or later on Mac
  • Outlook on the web
  • Outlook on Windows (Microsoft 365)
  • Outlook on Mac (Microsoft 365)

In addition to the basic platforms for support, you should also consider the complex business of which web viewer will be used to render your add-in. You should test Outlook on the web in the following browsers:

  • Edge
  • Chrome
  • Firefox
  • Safari (MacOS)

The Windows / Mac clients will use one of the following renderers to render your add-in:

  • Edge WebView2
  • EdgeHtml (MS Edge Legacy)
  • Trident+ (IE11)
  • WKWebView (Safari on iOS and MacOS)

EdgeHtml and Trident+ are no longer browsers and WebView controls used by Office add-ins, but we recommend that you attempt to support EdgeHTML. It usually only requires a small shim for the JavaScript spread operator!

We should also make a special note about mobile support for Outlook add-ins. Add-ins are indeed supported on iOS and Android Outlook, and we have implemented support for these in the past. However, due to Microsoft’s agreement with Apple and Google, the additional UI requirements for Android and iOS significantly increase the cost of doing this! Microsoft is stringent and inflexible in enforcing these UI requirements. We also see very little add-in usage on mobile platforms (most users don’t know how to install or use add-ins on mobile platforms). Check out the Outlook add-in design guidelines for more information.

You can see from the above list of platforms that testing an Outlook add-in requires significant effort. You should construct a test matrix to ensure you don’t miss anything. You should not skimp on this effort! See the section below on Microsoft Approval for why. 

Submit Your Add-In to Microsoft for Approval

Once you are happy with your add-in, you will probably want to submit it to Microsoft for approval to distribute it in AppSource. The process is similar to submitting a mobile app to Apple or Google with a similarly large set of “guidelines”. There are non-AppSource distribution mechanisms, but most companies use AppSource to deploy and publish Office add-ins.

Extensive documentation on AppSource requirements, guidelines, and the approval process can be found online, whether you want to know how to submit to AppSource with Partner Center, learn more about certification policies, or gain knowledge on Outlook add-in functionality.

We strongly recommend reading all of this documentation before starting the development of your add-in to ensure that Microsoft will accept your add-in.

Building an Outlook add-in is a complex business, and it helps to have a team with prior experience doing this! If you want McKenna Consultants to help with your Outlook add-in implementation, please contact us today!

For more information, check out our blog, including posts with more information about Microsoft add-ins and integrations

Nick McKenna
Since 2004, Nick McKenna, BSc, MBCS Biography has been the CEO of McKenna Consultants. McKenna Consultants is a bespoke software development based in North Yorkshire, specialising in Cloud development, mobile App development, progressive web App development, systems integration and the Internet of Things development. Nick also holds a First Class Degree in Computer Science (BSc) and wrote his first computer program at the age of nine, on a BBC Micro Model B computer. For the last 21 years, Nick has been a professional computer programmer and software architecture. Nick’s technical expertise includes; Net Core, C#, Microsoft Azure, Asp.Net, RESTful web services, eProcurement, Swift, iOS mobile development, Java, Android mobile development, C++, Internet Of Things and more. In addition, Nick is experienced in Agile coaching, training and consultancy, applying modern Agile management techniques to marketing and running McKenna Consultants, as well as the development of software for clients. Nick is a Certified Enterprise Coach (Scrum Alliance), SAFe Program Consultant (SAI), Certified LeSS Practitioner (LeSS) and Certified Scrum@Scale Practitioner. Outside the office, Nick is a professional scuba diver and he holds the rank of Black Belt 5th Dan in Karate.