Any Office 365 developer is able to build Add-ins for Office 365 applications like Word, Excel or Outlook. The Add-in model allows developers to build custom apps with business logic that runs inside of these Microsoft programs to achieve a specific outcome. The Add-ins will work across desktop applications for windows and mac as well as web-based browsers in desktop or mobile devices such as iOS, Android and Windows. Office Add-ins can be acquired in two ways: directly from the office store from the ribbon of the targeted application, or “side-loaded” by IT administrators.

All Add-Ins contains two key components

  1. Manifest Xml: This describes how the add-in is integrated into a specific Office program.
    • The xml contains several sections
      1. Permissions: when this add-in can be loaded (ex., read item, new email, etc.,)
      2. Rule: any custom rules that applicable so that the add-in opens only when the rule condition is met
  • Form Factors: since it is a web based browser rendering we need to configure how it should render in every device for example desktop, mobile devices. It is recommended to build responsive so that it works nice in all devices.

Here is an example of a manifest.xml for an Outlook add-in. Picture12. Remote Web URL: The remote web URL is where the user interface and business logic for the Add-in is hosted and typically makes use of web technologies such as JavaScript/Html.  If your Add-in requires more advance functionality or otherwise requires server-side logic, then you can use REST services hosted at the same Remote Web URL. This address is used within your add-in to load part of device configuration.

  • a. In the example Add-in we are using here, InterChange host the host the UI shown below.

Picture2.png

Completing SharePoint Tasks via an Outlook Add-in

The examples above are from an Outlook Add-in which we developed for the Akumina Experience Platform. This Add-in is intended to address a common customer request to respond to SharePoint workflow-managed tasks (e.g. approve a vacation request or the publication of content to a SharePoint website). Our customers prefer to do this directly from email because doing so from SharePoint is a several step process and not always mobile friendly.

The one big challenge we confronted in developing this Add-in was re-using the OAuth tokens to update SharePoint items. Any Add-in needs to authorize separately to update any SharePoint item. This is an example of a case where a developer would need to use server-side logic and REST services hosted at the Remote Web URL.

One benefit for any Akumina customer looking to develop this functionality is that the InterChange DevFramework includes a prebuilt REST API that can solve this authentication challenge, without extensive amounts of additional, custom code.

Using the DevFramework, developers can enable the authentication flow such that when the user clicks the Add-in, it securely communicates using the Interchange REST API through the Remote Web. On the first instance, the user is prompted to enter credentials, after which InterChange caches the tokens until the user signs out. Because this caching is handled on the server-side, the same token is used if a user opens their email on another device. Using this method Interchange makes it easier to create an Add-in which securely communicates to SharePoint to update the approval status.

Here is what the code looks like to build this functionality into an Add-in.

 

From client side, you use snippets like below:

Picture3.png

From Server Side you will have rest server code similar to:

Picture4.png

Let me know what you think about this approach in the comments. I am always excited to discuss these concepts so please reach out.