3

Our Outlook web add-in failed validation because in compose mode if the client does not support the recipients changed event we show a message to say the add-in is not supported.

We did this as we have two different use cases for the add-in. The read mode allows a user to search their database for existing customers and update their details. This only requires mailbox version 1.5. The compose mode functionality is new and allows the user to log emails to their database. For the compose mode to function it needs the recipient changed event which is only available in mailbox version 1.7

We did not want to remove access to the whole add-in for everyone on mailbox 1.5 who are already using the read functionality.

My question is, are we not allowed to provide a lower mailbox version in the manifest that caters to most of our users including some that are using On-Premises Exchange and only give access to the new functionality if their client supports it? If not, why give the option to detect the mailbox version or if a function is supported?

From the validation report:

The add-in did not pass compatibility tests for Outlook on the web (Classic experience) in Edge Classic. (Version: 44.18362.449.0).

The add-in displays an error: "This feature is not supported by this version of Outlook." when launched in compose mode of a message.

Please refer to the attached image: "ClassicComposeMode".

Based on the mailbox in use in your latest manifest (1.5), your add-in is currently required to support Exchange on premise which is tested as Classic mode in the Outlook Web App.If you do not wish to support Exchange on premise, then we recommend you increase the mailbox version to mailbox 1.6 or higher to bypass this test, as mailbox 1.6 and higher do not support Exchange on premise.

Image of the message we display in compose mode if the client does not support the recipients changed event:

enter image description here

Alec Harley
  • 31
  • 3
  • This is something that is achievable how you mention. You'd leave the requirement set to be 1.5 to support older clients and doing a isSetSupported check for functionality. The new clients would work with the new code as they would support 1.7. Could you share why the validation failed or with what specifically? – Outlook Add-ins Team - MSFT Jun 09 '20 at 21:51
  • I have updated the post with the failure message from the validation report and an image of the message that is displayed in the add-in if the client does not support the recipients changed event. – Alec Harley Jun 10 '20 at 08:12
  • Does your add-in support customers that are onPrem too which is why 1.5 is required as you state for read? – Outlook Add-ins Team - MSFT Jun 10 '20 at 22:22
  • Yes, we released the read mode of the add-in about a year ago and we do have some onPrem customers using it. The compose mode was added recently to support a new feature in our software. The whole compose mode feature hangs off of the recipient changed event. If the client doesn't support that event then we show the message above as soon as they load up the compose mode of the add-in. – Alec Harley Jun 11 '20 at 07:45

1 Answers1

0

We managed to get the Outlook Add-in through review without changing the behaviour described in the post.

We put the Add-in back through review but this time we added more information about the change to the 'Notes for certification' box that you can fill in before submitting for review.

We added information about what exactly had been changed and why the message was shown to clients that don't support the 1.7 requirement set.

Alec Harley
  • 31
  • 3