Outlook Apps - a new approach worth considering

A conversation with a Microsoft engineer at the Microsoft Exchange Conference caused me to wonder if Outlook apps are being overlooked by many companies as they seek to extract value from their deployments. Or indeed, to justify an upgrade to the latest generation of Microsoft Office technology.

You might recall that Outlook apps are a write-once, reuse on all platforms mechanism that allow developers to access Exchange data such as message and appointment items and take action based on their content. Microsoft maintains a set of available apps (some written by third parties) that you can install into your organization.

Bing Maps is one out-of-the-box example – it looks for address information in an item and displays map information if an address is found. Although you might quibble about the app’s ability to handle non-U.S. addresses, it serves to illustrate the concept of examining item content and taking appropriate action.

The MessageHeaderAnalyzer app provides a different example. Instead of item content, the message headers are parsed and analyzed to provide a detailed step-by-step description of the path that a message took en route to the recipient. This app is useful to administrators but of little obvious benefit to most other users, unless of course they have nothing to do and examining SMTP headers seems like a better use of their time than checking in on Facebook or consulting the latest cute kitten video on YouTube.

The point here is that Microsoft has provided a way through Exchange Web Services (EWS) to grab information from items that can then be processed for business purposes. Apart from Outlook 2013, the app will also run on any platform that Outlook Web App (OWA) supports, including OWA for iOS and OWA for Android. The app will also run on Windows Phone, but only if you use the browser to run OWA (see below) instead of Outlook Mobile. Because Outlook apps depend on a web server to provide information about apps, the apps can be published and available in an on-premises, hybrid, or Office 365 environment.

Given that so much business data is circulated via email, it makes eminent sense to make that data more usable in the hands of users. It seems like Outlook apps are a good way to do this, but only if you imagine the possibilities of what might be possible within the context of your organization.

Take travel requests for example. Many companies circulate travel information in email as employees seek approval from managers to attend conferences, such as Exchange Connections in Las Vegas next September. These messages probably contain the name of the traveler, the reason for travel, the dates, and the location, so it’s not particularly difficult to see how you might extract that data and use it as the basis for constructing a formal travel request that a manager can approve or checking what the costs of flights and hotels might be in Las Vegas during the conference (but do stay at the Aria, the conference hotel).

I hear that American Express might be working on such an app, which is nice for companies who use American Express to manage their travel. If you don’t, there’s no reason why you shouldn’t be able to write a pretty functional app.

Of course, knowing how to start is always a problem. As it happens, Microsoft publishes some pretty good example code to help you begin. You can start with an easy example that demonstrates how to retrieve information from a message and then move on to something more complicated such as “Sample: Create a mail app to display in Outlook hierarchy information from Active Directory.” The title is a mouthful, but really it’s just a way to extract information about recipients on a message from Active Directory so Outlook can display their photos, job titles, and anything else that might be of interest in Active Directory. The code works, it’s a great start to getting to know the components of an Outlook app, and Visual Studio makes editing painless.

The history of Outlook and Exchange is littered with examples of APIs that never went anywhere fast. CDO Routing Objects is my favourite – it had enormous potential because so many forms are routed inside businesses – but the API died a slow and lingering death soon after it was launched with Exchange 5.5 SP1 in 1998. I don’t think that Outlook apps will disappear and give it a good chance of being successful. That is, if companies decide to actually use this interesting and worthwhile capability. As always, the acid test of the market will decide.

Follow Tony @12Knocksinna