Deploying OnSend Outlook Add-ins?

If you have been developing OfficeJS add-ins for Outlook Online (or Exchange 2016 Outlook Web Access) you might not know that you now have the ability to create OnSend add-ins. That is add-ins that can trap the send of an email, test for conditions (such as getBodyAsync() or getSubjectAsync() to look for content) and if they fail, prevent the message from being sent. I recently blogged about it here:

The Most Anticipated OfficeJS Feature is Here

First thing to note about these add-ins is that they cannot be created for or uploaded into the store. The second thing to note is that they MUST be configured first in order to run. The third thing to note is that if you are building an on-prem Exchange based solution, you have to have Exchange 2016 CU6 installed and a bit more. The full details of how to configure the environments (either Office Online or On-prem) are detailed here:

On send feature for Outlook add-ins

If you look this over, there is quite a lot to do. How would you like one single PowerShell command to type? Maybe something like this:

[code type=”powershell”]



wlEmoticon-hotsmile.png Well, I just published the first version of this script on GitHub:

All the details you need to know about it are there in the README.MD. However, if you have any questions or issues, please let me know.


3 thoughts on “Deploying OnSend Outlook Add-ins?

  1. I have developed and tested an On-Send Outlook Addin using Visual Studio to debug, and tested in Outlook and OWA. Now it is finished, I am confused how to organise/package the manifest and web files to my IT Manager so they can install it on the server. I would be very grateful of you could point me to some instructions! Thanks, John.

    • If you used VSCode and the default Yeoman template, compile/webpack the add-in into a dist folder by typing (npm run build). Then send the contents of the DIST folder to your admin. For a full Visual Studio add-in, you would need to run the PUBLISH option from the Build menu. This will create a PUBLISH folder which you will give to you admin.

      Now, it sounds like you might not know the name of the server you will be publishing these to. So, you will need to supply the admin with instructions to modify your manifest as well. For example, you manifest might have the path https://localhost:5431/content/taskpane.html (or similar) … You will need to have them change that to the server, so if they place it on “CORPSERVER”, you would have them change it to the full path where it is stored:… as an example. If you DO know the name of the server and the folder where they will place the add-in, you can edit the manifest yourself and send it to them. But this is a bit of an iterative process I have found in that IT folks are not at all certain what you are doing or why and how to get things deployed correctly. So, expect some back and forth to get it right.

      Finally, the manifest file will need to be installed by the admin in the Office 365 control panel. There are a lot of articles on the web about this, they would just follow that process and assign the users that needs access to your add-in.

  2. That makes a lot of sense. I have used ~remoteAppUrl for my location in testing, but I didn’t know this will have to be changed, so I will specify this when I publish it. Thanks very much for your help!

Leave a Reply