Office Online UI updates


There have been some subtle changes to the Office Online user experience in the past week or so. Office Online are the office applications such as Word, Excel and PowerPoint, they render a web based version which allows you to edit and read content directly within the browser.

The image below shows the reading view of a Word document. Note how the application bar now has a new layout and different options



The link back to the document library location is now within the grey area rather than on the header bar. In the image below you can see the library title ‘operations’.


The other options now appear on the right-hand end. As you can see from the image below some of the common options are now available without opening the file.


The ‘Edit Document’ menu provides us the links to edit online or in the desktop application.


The ‘Print’ menu item prints off the document as a PDF


The ‘Share’ menu item launches the Sharing dialog.


The ‘Comments’ menu item opens up the commenting functionality.


The ‘…’ menu brings up some other useful features.

The ‘Find’ menu brings up an in-document search box. Personally I’d like to see this as one of the primary options as it is a training challenge to educate people that it exists.


Other options allow for the in place translation using the ‘Translate’ menu option. The ‘Download’ does exactly as you’d expect and downloads the file, as does ‘Download as PDF’.

The final option which is worth mentioning is the ‘Embed’ option. As you can see from the image below it has some pretty neat features.


We can set the dimensions and some of the interactions available such as enabling print and the start page.

While they sneaked in under the radar these changes have made Office Online even more capable within Office 365.

My first day at EasySharePoint


It’s been eight years since I was the ‘new boy’ in class so today is an exciting day for me. After years working as a Solutions Architect in various guises today I become Chief Technical Officer at EasySharePoint. EasySharePoint are a Microsoft Partner based in London. They help clients realise immediate value from their Microsoft Office 365 investment by delivering a proven intranet and collaboration platform with their EasyShare Online product. The EasyShare product was also awarded Best Global Intranet 2014 by The Institute of Internal Communications.

Why EasySharePoint?

Forrester’s June 2014 report ‘New Development Platforms’ notes a change in trend from enhancing SharePoint with custom solutions to enhancing SharePoint with pre-built solutions. Forrester identifies low code platforms as gaining popularity for their speed in delivering value to the business in addition to the following benefits:

  • Slash the hand-coding needed to deliver applications: Low-code platforms minimize hand coding and speed up delivery by providing visual tools for quick definition and assembly of user experiences.
  • Address all customer channels, including mobile: These platforms support responsive design and mobile-ready functionality that makes it as easy as pushing a button to extend the app to work across other channels, including tablets and smartphones.
  • Provide a single control point for configuration, delivery, and maintenance of apps: Low code platforms provide a unified and centralized environment for configuration management, role-based access, authentication, and repository control of apps and configuration components.

Analysts for a long time have called out custom development for being lengthy and therefore expensive, not always delivering best practice and forcing a focus on code rather than business adoption and value. I wanted to join a product company because I recognised the challenges of on-premises would only be compounded as organisations move to Office 365 if they tried to replicate the old model by custom developing the platform.  The EasyShare Online app product, which quickly and intuitively stands up Office 365 sites, Yammer, Lync and extends Office is a great way for any organisation to enjoy the benefits of Office 365 – with the benefits of customisations – but without the hassle of custom development.

So why has it taken so long for the market to recognise products deliver better value than custom development? Simply put, organisations which make up the Microsoft eco-system are predominantly services businesses.

Where it is certainly the case that custom development is the right approach for applications that are unique to the way that as business operates the vast majority of custom work has delivered generic capabilities that could be met with an off the shelf product because this is how the IT community has long been set up. Moving from custom to product to a large degree requires one to cannibalise their own business.

This is a big step and one we have watched Microsoft themselves take with the push to move clients to Office 365 and away from on-premises technology. The reality is that this was a move which served the interests of organisations rather than Microsoft themselves. Office 365 and Azure deliver better (and evolving) productivity tools to clients, cheaper. The shift in Microsoft’s own focus towards organisational adoption and away from software sales has also benefited clients enormously and simultaneously created a new workload for Microsoft. In the world of Office 365 every individual user counts.

This has been a transformation that has ultimately led Microsoft to a moral victory; as Office 365 adoption increases organisations globally will be using cheaper, better technology.

EasySharePoint has been ahead of this step change, building their first SharePoint intranet product for SharePoint 2007, with later versions for 2010, 2013 and Online.

The EasySharePoint approach is distinctive. The EasyShare Online product delivers Office 365 in hours rather than months, thanks to EasyShare’s pre-built capabilities allowing a business to focus on content and adoption. The product includes:

  • New features that extend what is available Out Of The Box
  • Integration with Yammer, Lync and Office
  • An easy branding tool
  • A fully multi-lingual experience
  • A fully responsive mobile experience across all major devices and browsers

…and what will I be doing there?

EasyShare Online is the most widely used pre-built Office 365 app in the market. As the Chief Technical Officer my main responsibility will be designing the product roadmaps and supporting our clients and partners using EasyShare Online and Office 365. I’ll be working closely with our Technical Strategy Director and production team to design our new product capabilities.

Alongside all of this I’ll be getting more time for community activities such as speaking and blogging. I’m very excited about the new job at EasySharePoint and all the new ideas that will find their way into our products in the near future.

Creating a simple redirect app for the App Launcher


As we saw from the previous article Adding GitHub to the App Launcher the Office 365 user experience now incorporates the App Launcher as a persistent navigation element across the whole suite. Combine this with the Access Panel in Azure and you have two simple ways to provide a user with a navigation item. As you can see from the screen shot below, including last articles addition of GitHub.

Imagine an organisation wants to take advantage of the App Launcher to provide a link to their users for the company public website. On the surface this isn’t such a bonkers request. Many organisations have some elements of their internal intranet hosted within Office 365 and often they require a link to the public facing sites as well. It makes sense then as the App Launcher provides a globally available menu system that the intranet owner might ask for this link to be provisioned. Ok so far, a sensible request by the stakeholder….

Well if we cast our minds back to the types of application that can be displayed:

  • Office 365 applications – If you are using Office 365 such as Exchange and SharePoint and the logged in user is assigned a license then these will appear. The user will be automatically signed in when they click any of the Office 365 apps.
  • Microsoft or Third Party apps configured with Federation based SSO – If an Azure admin has configured the app with single sign-on mode set to ‘Azure AD Single Sign-On’ then when a user clicks the app they will be automatically logged in assuming they have been explicitly granted access to that application.
  • Password based SSO without identity provisioning – These are applications the Azure admin has added with the single sign-on mode set to ‘Password based Single Sign-on’. It is important to realise that all users authenticated to the Azure AD will see these applications. The first time a user clicks one of these apps they will be asked to install a lightweight browser plugin for IE or Chrome. Once they restart the browser the next time they navigate to that app they will be asked to enter the username and password combination for that app. This is then securely stored in Azure AD and linked to their organisation account. The next time the user clicks that app they will be automatically signed in with the credentials they provided. Updating credentials in the third party app needs the user to update their Azure AD stored credentials from the context menu on the app tile.
  • Password based SSO with identity provisioning – These are applications the Azure admin has added with the single sign-on mode set to ‘Password based Single Sign-on’ as well as identity provisioning. The first time a user clicks one of these apps they will be asked to install a lightweight browser plugin for IE or Chrome. Once they restart the browser the next time they will be automatically signed in to the application.
  • Application with existing SSO solutions – These applications are configured with the sign-on mode set to ‘Existing Single Sign-on’. This options supports the existing methods of SSO such as ADFS 2.0 or whatever the third party application is using.

None of these sound like a ‘simple’ type of hyperlink navigation item do they? They all assume the need for some kind of sign-on or application.

So at the time of writing this article there is no way to add a simple static url into the icons. Microsoft might pull this feature in at some point in the future, but for now we need something sensible to help us implement it.

NB: When researching this challenge I did stumble upon one blog article which was suggesting using jQuery to inject items in the html of the App Launcher. While in reality the author had it working it would be something I’d steer well clear of for the following reasons:

  • Microsoft ‘own’ the UI/UX for the App Launcher which means they can make breaking changes any time they like leaving you with a broken implementation at best
  • The article could only get this to work across SharePoint Online as the author could inject the required script. This meant that users outside of SharePoint lost this set of icons in things like Exchange.

So where does that leave us? Simple really we need an application registered with our Azure Active Directory which can redirect the user.

Creating our redirection app

So we have two options for this, manually craft an Application and register it with our Azure AD Applications or use the Visual Studio tools to help. For this article we’ll opt for the Visual Studio root and rather explain what’s happening behind the scenes as we go.

So lets get going by cracking open Visual Studio 2013.

Lets create a new MVC Web Application called ‘SimpleRedirectorApp’ and click OK.



Lets be good citizens and change our app to use SSL. Change the Project property to SSL Enabled to true.


Then copy that URL into the properties page on the Web tab.


Save the project and run it.

At this point you should see the normal templated MVC page running on your localhost under SSL.


So at this stage we have a basic MVC web application up and running. Now lets switch into our Azure portal and take a look at the applications listing.

This is all the applications I have configured in the Azure Active Directory. You’ll notice from the screen shot below our new app is not yet listed in the applications and thus Azure and the App Launcher no nothing about it.


If we were doing this manually we would go through the steps to ‘Add’ the application here. For this run through we’re going to jump back to Visual Studio.

We are going to use the Office365 Tools to add a connected service which wire up our app the associated Azure AD for us.

So from the context menu of the project chose ‘Connected Service’.


Click ‘Register your app’.


Sign in with a user who is an Azure AD admin / Tenant admin which is normally one and the same.


This will then show you information about your application.


Click ‘App Properties’ and make any changes from single to multi tenant if you require.


Note that the URLs are being displayed which match where our App will run from at the moment. When you choose to publish these elsewhere for Production you update these values.

Now when this wizard finishes it has done a few things. Firstly its added a set of things to the web.config file to store the Client Id etc.


Next if we switch back to our Azure Portal you’ll see the App is now being listed.


Clicking in we can view the settings that have been made.


One of the things we can’t do from the Visual Studio tools is set the Logo for the App. This is important to do as it’s the visual icon in the App Launcher. So click the ‘Upload Logo’ from the menu bar.


Choose an image which matches the specifics in the dialog box. I’m going to be linking to my companies website so created a quick icon based on our logo.


Scrolling down you can see the URLs listed and the permissions the App needs to run. Notice at the moment we don’t ask for anything other than delegated permissions on the Azure AD to enable SSO and read the profile of the user. That’s all we need.


Once the App is configured we need to assign users to it so it shows up for them. So click the ‘Users’ tab and find the user you need to assign. As you can see from the screenshot I’m just going to assign myself it for now. Once highlighted click ‘Assign’ from the menu bar.


Now when you browse to your Office 365 tenant and open the ‘My Apps’ page you can see our new App listed. As you can see from the screen shot below.


At the moment we have to manually ‘pin’ this new app ourselves Sad smile hope Microsoft add features to do this from the portal at some point.


So now it shows up in the App Launcher. Hooray you say… click it and what happens… we get the boring old MVC default page in a new tab. (assuming you still left the app in debug, remember its localhost at the moment).


So only one more step to go. Lets make our App go where it should, to the all important public website.

Open the HomeController.cs and find the Index method.

Change it from this


To this


We changed the result object to the RedirectResult type and provide it the url of our public site.

Now rerun our localhost app and it should redirect straight to the website.


Now when we click the App from the App Launcher we get a new tab and the App handles the redirection to the specified site.

Happy stakeholder Smile

As I mentioned earlier one of the best things about this approach is that it is truly suite wide as you can see from the screen shot of the users Calendar below.


In a more detailed scenario you might want to add more features to the redirection app and make it configurable without hard coding, but this was the basic how to Smile.

Adding GitHub to the App Launcher


Lets start with a little background

One of the latest features released to Office 365 and Azure was the ‘App Launcher’. This feature (Microsoft Announcement) provided a consistent menu of applications that can be launched by the user. Azure Active Directory now provides an easy way to integrate to many SaaS platforms. It provides identity and access management features through the Azure portal and the Access Panel for users to discover apps they have access too. The App Launcher leverages the same underpinnings within Azure to provide the suite wide UX within Office 365.

Azure Access Panel

Information about setting up Application Access in Azure Active Directory can be found here: Another feature we won’t go through but is worth mentioning is the ‘Change Password’ feature on the profile tab.

This is a screen shot of my tenant Access Panel. You can browse to yours using:


The Access Panel can serve several different types of application:

  • Office 365 applications – If you are using Office 365 such as Exchange and SharePoint and the logged in user is assigned a license then these will appear. The user will be automatically signed in when they click any of the Office 365 apps.
  • Microsoft or Third Party apps configured with Federation based SSO – If an Azure admin has configured the app with single sign-on mode set to ‘Azure AD Single Sign-On’ then when a user clicks the app they will be automatically logged in assuming they have been explicitly granted access to that application.
  • Password based SSO without identity provisioning – These are applications the Azure admin has added with the single sign-on mode set to ‘Password based Single Sign-on’. It is important to realise that all users authenticated to the Azure AD will see these applications. The first time a user clicks one of these apps they will be asked to install a lightweight browser plugin for IE or Chrome. Once they restart the browser the next time they navigate to that app they will be asked to enter the username and password combination for that app. This is then securely stored in Azure AD and linked to their organisation account. The next time the user clicks that app they will be automatically signed in with the credentials they provided. Updating credentials in the third party app needs the user to update their Azure AD stored credentials from the context menu on the app tile.
  • Password based SSO with identity provisioning – These are applications the Azure admin has added with the single sign-on mode set to ‘Password based Single Sign-on’ as well as identity provisioning. The first time a user clicks one of these apps they will be asked to install a lightweight browser plugin for IE or Chrome. Once they restart the browser the next time they will be automatically signed in to the application.
  • Application with existing SSO solutions – These applications are configured with the sign-on mode set to ‘Existing Single Sign-on’. This options supports the existing methods of SSO such as ADFS 2.0 or whatever the third party application is using.

Full details about the Access Panel can be found here:

App Launcher

The App Launcher is the name for the UX within the Office 365 suite. The screen shot below shows the fly out menu active on my tenant. You can see all the apps that this user is assigned licenses for are visible, also admin as this user is a tenant admin.


You’ll also see the ‘My Apps’ option in the bottom right corner. This takes you to a fully immersive experience listing all your apps. As you can see from the screen shot below.


This page lists all the applications from Azure AD applications as well as anything you have installed within your OneDrive for Business site on SharePoint online.

Configuring GitHub through the App Launcher

So we’ve taken a whistle stop tour around the Azure AD Access Panel and App Launcher lets now look at how to add an application to it. For this article we’re going to look at providing our users SSO for GitHub. The Azure AD links above show how to connect up to all sorts like SalesForce, DropBox etc, but Microsoft’s latest code repository choice isn’t listed. As all the  Office Dev Code Samples these days live in GitHub it makes sense to provide a SSO implementation for your dev teams. Here’s how.

First thing to do is log into the Azure portal. You’ll see the connected Azure Active Directories listed. You might have several or just your Office 365 directory. You pick the one you want the application to show up in. In my example I’ll pick my main tenant.


When you click the required AD row it will switch into the dashboard for that AD service. As you can see by the screenshot below there are lots of different things you could do here, but we are going to focus on the ‘Applications’ tab only.


Clicking the ‘Applications’ tab shows the connected applications. In the screen shot you can see I’ve been busy with the Office 365 APIs Smile. Also note that this AD is connected to my Office 365 subscriptions so both Exchange and SharePoint are listed. These don’t have the same degree of settings available as other applications though.


So to add a new application click the ‘Add’ from the menu bar. This pops a light box as you can see below. There are two options, first is to add a custom application (a topic for a further article) which you are developing, the second to connect a service from the gallery. At the time of writing there are about 4500 services and applications available in the gallery so it’s worth having a peek through. GitHub is an existing service so we need to click ‘Add an application from the gallery’.


Rather than browse it will be easier to type ‘GitHub’ in the search box. You’ll see the below. So click the ‘tick’ button to confirm.


Now GitHub is connected to your Azure AD as an application. We now need to configure the SSO settings and assign some users.


Click the ‘Configure single sign-on’ button to setup the SSO for GitHub. The light box that pops up has two options, first is the Password Single Sign-on, the second is for existing Single Sign-on. Both are explained in more detail above. We are going to choose the ‘Password Single Sign-on’ to connect as we don’t already have anything else configured for SSO with GitHub. Click the ‘tick’ to confirm.


We have now configured our chosen method of SSO. It’s time to assign some users. So click the ‘Users’ tab. From here all the users in your AD are going to be listed so you probably want to search using the slightly hidden search feature on the table header far right to narrow down the view to users you want.


Once you have your desired user select them by clicking the row. And then choose ‘Assign’ from the menu bar.


The light box that pops up allows us to confirm that user is about to be assigned access via SSO to this application. The checkbox feature we’ll come back to later in the article, for now leave it unchecked. Click the ‘Tick’ to confirm.


So there we have it, in some fairly simple steps we have configured SSO with GitHub via our Azure Active Directory. Lets now take a look at the implications for the end user experience in both the Access Panel and App Launcher.

Access Panel user experience

Now GitHub will show up for the assigned user. In the screen shot you can see the new GitHub tile has appeared. It can sometimes take a few minutes to update and the page may display a refresh message when changes have happened that need to reload.


As mentioned earlier a user can maintain their stored credentials via the Access Panel. As you can see from the screen shot this option is available from the tile on the Access Panel.


Clicking for the GitHub App very first time from the Access Panel invokes the browser plugin installer as you can see from the screen shot below.


In this example I was using Chrome, so here are the pop ups which trigger the install.


Confirm the installation dialog.


Next time you click the GitHub App you will be asked to enter your credentials as Azure AD does not yet have any stored. Enter the desired credentials and click ‘Sign In’.


Now when you click it the Azure SSO will kick in via the browser extension and log you in with the stored credential. Blink and you’ll miss it though, took me five attempts to screen grab the login step.


And there you have it, signed in to GitHub with the SSO password.


App Launcher user experience

The Office 365 App Launcher MyApps page now sports the same GitHub icon under ‘My Apps’.


Clicking for the GitHub App very first time from the My Apps page invokes the browser plugin installer as you can see from the screen shot below.


The next time you click the GitHub App the same SSO process as above is invoked and you get signed in.

One feature of the App Launcher which the Access Panel can’t do is allow the user to pin the App to the flyout menu. To do this navigate to the ‘My Apps’ page and from the context menu of the app click ‘Pin to app launcher’ as you can see in the screen shot below.


As you can see this then pins that app to your App Launcher menu.


Other stuff worthy of a mention

App Launcher where a user has no App assignment

Below is a screen shot of a different user within the same tenant and Azure AD who doesn’t have GitHub assigned as an App. As you can see their ‘My Apps’ page doesn’t list it.


Assigning a credential on behalf of a user in the Azure Portal

We mentioned the checkbox earlier. If you wanted to set the username and password during assignment check the checkbox and you get the option to enter the credentials on behalf of the user.


So why is this important? Well consider situations where you don’t want a user knowing or setting the credential. For example a situation where the organisation has a marketing twitter account. You can now provide SSO for the marketing team by setting up their credential on their behalf. They can still obviously change it in Twitter but it removes the need to email everyone the password.

Removing a user app assignment

Removing the user assignment is as easy as selecting them and clicking ‘Remove’ from the menu bar.


App dashboard

Another thing work mentioning is the App dashboard. Here you can see the login activity and some basic information about the app. What is really useful though is the Single Sign-on url. This is a unique url for this SSO’d app and pasting it in effectly jumps the Access Panel or App Launcher steps and navigates directly through the sign-on process. This would be useful if you are considering email or Yammer posts with links directly to the application.



Hopefully you’ve found this useful Smile and seen how easy it is to take advantage of the SSO features to improve your user experience.

So we now have GitHub easily available to all the assigned users, probably starting with the dev team.

The importance of naming your Office 365 tenant

There is a frequently referenced part of Romeo and Juliet where Juliet seems to argue that it does not matter that Romeo is from her rival’s house of Montague, that is, that he is named ‘Montague’. The reference is often used to imply that the names of things do not affect what they really are. When it comes to choosing a tenant name…. They really do!

Within Office 365 the choice of the tenant name is something you really need to think about from day one. Failure to do so often leads to later headaches and unhappiness.

Here are some points to consider:

  • The tenant name always appears in the SharePoint url for example so you need to consider whether the url makes sense. Also you might be typing it a lot so choosing something short is great for users.
  • Has the right team in your organisation been involved? The name will be there an awful long time so make sure the right teams are involved in the choice, does your marketing or legal team need consulting. Does the name factor into the company growth?
  • Is the name already taken? If your desired name is in use Microsoft can contact the current owner and you may be eligible to regain that name. Often other elements of an organisation may well have already claimed the main name during a POC etc. This process can take a very long time upwards of 120 days.
  • If you choose the wrong name you will end up with a migration project entangled with rollout project.
  • You need to make sure you get the right licenses are assigned on the tenant. If the tenant gets created incorrectly it can sometimes lead to deletion and recreation which can take upwards of 60 days. This is due to the teardown process SLA for a tenant to release the name for reuse. Also Microsoft are the only ones who can perform this action.
  • The tenant name is used in cloud identities in the email address for example
  • The choice can be complicated if the company is split into groups or operating companies which have strong brand identity.

So when considering Office 365

The standard set of questions should be:

  • Do you have an Office 365 tenant?
  • What is the tenant name (i.e. <>)
  • Are you happy with this name to appear in the URL for (future) SharePoint Online? Has this been signed off by your comms / marketing team?

If you want to set up a new tenant for a client and want to know whether the name is free or not, use this awesome little Azure App:

Naming a document in Office Online


Office Online is the web based versions of the common Office application like Word, Excel and PowerPoint. These are great productivity boasters in Office365 allowing most common document editing experiences to be performed within the browser without the need to download the actual document locally.

As a user you can create a new file directly within the browser from the ‘New’ menu item shortcuts on every document library.

In OneDrive for Business it looks like this.


In a team site it looks like this.


Lets look at an example when we click the ‘Word document’ from the OneDrive new menu.

It opens our new document in Word Online.


As we can see when we return to the OneDrive library our new document has been created but it has been called ‘Document1’.


So how can we rename it to something sensible?

We can do it via the Edit Properties menu


Change the file name in the edit form and click save.


This now shows the file updated.


There is an easier way.

Lets repeat the action from the new menu to get a new document. This gives us another ‘Document1′ Word document. So we should be able to switch into backstage to update the file info right…. By choosing ‘Save As’ and picking a filename.


Well no actually this doesn’t work in Office Online as it is clever enough to be already saving directly into the online library.


Clicking ‘Save’ tells you as much.


So how can we change the file name? Well its actually so simple when you know how.

Click the ‘Document1′ name in the header bar while editing the document. And simply overtype your desired name.


When you change it you can see the change back in the main library view.


SP Connect 2014 Presentation


Tuesday 18th and Wednesday 19th saw this years SP Connect 2014 take place at the Meervaart Theatre, Amsterdam. It was a great event organised with so many quality speakers and companies in attendance. It was a privilege to be invited to speak Smile

I presented a session on the new Office 365 APIs with Chris O’Brien, the slides from our session can be seen below. I hope everyone found the session useful Smile I certainly enjoyed presenting to such an interactive audience.

Our session demonstrated the latest release of the Office 365 APIs which recently GA’d. We used the samples available on GitHub, The Web Client library used the MVC5 starter example. This is a single tenancy app which uses the three elements of the Outlook Client library and the Auth models. It’s a great place to start as it shows a good spread of the API. The second demo showed the preview File Handler which shows how to extend Office 365 with a file extension capability. The pictures below give a sneak peek to how it looks when its working. The sample can be found here




Thanks to everyone who attended the session, hopefully I’ll be back at next years event. Special thanks to Daniel Laskewitz for allowing me to use his session picture in this article Smile

Document conversations does not equal hover panel post


Back in June 2014 Microsoft/Yammer announced the arrival of a new feature call ‘Document Conversations’. Available at the time of writing in some tenants (full roll out is in progress) this feature adds a fly out panel to Document Libraries in Office365. The full details of the feature can be seen on the Office Blog here:

Our Office365 tenant is setup with ‘First Release’ which provides upcoming updates about two weeks prior to their formal rollout. Over the last month we’ve seen the Document Conversations feature coming and going. Hopefully it will be fully completed at some point very soon. During this rollout I took the time to try out the feature and get a feel of how it works.

Document Conversations in action on OneDrive for Business

Browsing to my OneDrive for Business page nothing different appears on the display. As you can see below it still looks the same as when the ‘Site Folders’ rolled out earlier this year.


So to invoke the ‘Document conversation’ window you have to actually browse to the document. As you can see below a new right-hand slither has appeared with the Yammer logo and an indicator to click to expand.


Clicking the Document Conversations bar expands it into the right-hand pane, much like the Apps for Office do in Office 365 Pro. On first use or when you’ve not signed into Yammer you will be prompted to sign in. The screen grab is once sign in has been done. First thing to note here is it isn’t displaying any threads, that’s simply because I had newly created this document for the purpose of this article.


Next lets create a new ‘Yam’ from the ‘Document Conversation’ pane. At this time it allows the user to select a group to post the ‘Yam’ into, interestingly there is no way to setup a default for this. I think it would be awesome if Microsoft had provided a ‘default group’ setting on the hosting Document library settings, as i suspect the feed is using the Yammer Embed which has the ability to set a default group. That way users could configure their defaults and avoid everyone posting into the ‘all company’ group.


After posting the ‘Yam’ it can be seen in the ‘Document Conversation’ pane. Note how its being presented as an OpenGraph object and not a url.


Below is an example of a reply to the conversation thread.


This is the same conversation thread within Yammer.


Posting from SharePoint to Yammer

Before the ‘Document Conversation’ feature was designed and built one of the first Yammer integrations with SharePoint was the ‘Post’ option which appeared on the document hover panels. The screenshot below shows the ‘Post’ option on the same file we just used for the ‘Document Conversation’ demo.


Clicking ‘Post’ launches a modal window with a url in the message body so you can type a ‘Yam’. As you can see from the screenshot this is a pretty basic UI.


The screenshot below is the ‘Post’ in the yammer group.


Comparing the two approaches

So we’ve seen how both approaches seem to work. The one thing that i found puzzling was in the Yammer group i’d seen two threads about the same document. One from the ‘Document Conversation’ pane and one from the ‘Post’ modal dialog. This didn’t make sense on first glance I would have expected both to reference the same item (url) as the OpenGraph object.

Document Conversation

The ‘Document conversation’ thread has the following JSON returned from the API.


The body of the ‘Yam’ contained a url of the file path with query string ?web=1 which when launched opens the document in the Office Online app.


The OpenGraph object is detailed below. Again not the url has the ?web=1 querystring.


Post from hover panel

The ‘Post’ thread has the following JSON returned from the API. We can see nothing special in the thread itself.


The content returned by the ‘Yam’ this time shows the WOPI (Office Online) url has been used.


The view of the attachments xml confirms the information.


So doing it again

Via ‘Post’ creates a brand new post. The ‘Post’ feature adds a brand new OpenGraph object and thus starts a new thread, rather than finding the existing thread and presenting it back to the user in the popup window.



So the two methods use different urls thus become two different OpenGraph objects.

It would be great if Microsoft could bring them into alignment so that there is one solution url so all conversations appear in the same thread.

Delve YamJam summary


This week people who had their Office365 tenants setup with ‘First Release’ started to see the long anticipated Delve (formally Codename Oslo) arriving on the tenants.

Microsoft organised a YamJam for Delve in the Office365 Technical Yammer network here:

This article is a summary of the information which is correct at the time of writing.

Is Delve coming to on-prem?

A hybrid approach is more appropriate due to the complexity and processing power required to drive the OfficeGraph engine. There will be APIs to allow connection to other data sources for the signals driving the OfficeGraph.

Microsoft are planning a hybrid connector that can integrate signals and content from on-premises. They have no current timeline. This is probably going to feature for the scenarios where Lync and/or Exchange have an on-premises installation.

Privacy concerns

Some users concerns around privacy topics. The example cited was that a company Delve was showing trending documents for certain HR documents for example, psychological assistance and domestic partner coverage and maternity benefits. The question was around being able to exclude certain content from producing signals.

The documents could be excluded through the normal SharePoint permissions capabilities. Delve relies on the search index, so excluding a file or folder will exclude it from Delve as well.

Currently there is no feature to exclude documents from Delve but have them available to everyone via SharePoint/Search.

Side note about storing documents from HR in Yammer and the fact that ‘viewing’ it shows up in the activity feed in the top right. This gives people visibility on what other users are looking at, so someone looking at HR docs around maternity is kind of announcing that interest to the whole organisation. Not so good.

Delve does not show ‘who’ viewed a document ever. Trending is invoked when multiple people who have a relationship with you have accessed the doc. The author is the named entity. This is slightly confusing in the UI. At a glance the name appears to be the user who viewed the document. Careful communications would need to be done for this on rollout.

Delve only shows if someone modifies a document (this is available through SharePoint anyway). Delve doesn’t show who viewed the document, where many people have viewed the document Delve says several of your colleagues have viewed this document, but never divulges the names.

‘Trending’ does not mean a person viewed it, only that your colleagues are generating activity around it. (no information on the definition of activity).

CSOM / JSOM API availability

OfficeGraph will have an API. Current information is available here:

Could OfficeGraph be consumed in PowerBI?

In theory this should be possible as its got an API.

Restricting the rollout to specific users

Like an ESN Delve thrives on a wide and deep network of users. By restricting to s subset an organisation would fall into the ‘doomed social pilot’ trap of not enough signals to add the absolute value. Obviously this is an ESN success perspective. Organisations will have reasons for this request, regulation, change mangement and security were all cited.

Also it was noted that you can disable Delve at tenant level, it was unclear as to whether this is the Delve UI alone or included the OfficeGraph underpinnings.

When will I get it?

Currently this is being rolled out to ‘First Release’ tenants first.

What is the Delve UI item display limit?

Answer: 36 documents before adding filters by using search. Microsoft said 36 was chosen as the starting point through internal MS trail data. Their data showed that click rates dropped to zero at a certain point in the page.

Microsoft’s choice of name Delve

Mixed feelings, those who aren’t English speaking said that Delve doesn’t always have a real meaning in some languages. Others just preferred Oslo, and thought Delve didn’t really jump out. As with most questions like this, nothing really bad comes of the name. Lets just hope it doesn’t get a rebrand in 6 months ;)

How will Delve handle existing content and groups?

Being search based it can pick up everything in the tenant today.

Which plans get Delve?

Office365 E1-E4 and corresponding Gov and Academic plans.

At first release Delve gets signals from Exchange, OneDrive for Business, SharePoint Online and Yammer. Primary content surfaced from OneDrive for Business and SharePoint Online team sites.

What determines the people list?

This is the top five people you interact with.

Useful links

Delve documentation:

Delve for Office365 admins here:

OfficeGraph API documentation

Thoughts about migrating content into Yammer from forums


This article hopes to cover the considerations and possible approach for planning and migrating existing forum content into Yammer. Yammer doesn’t provide any form of ‘migration’ or ‘import’ for other system content. They take the stance that the working paradigms created by Yammer are unique to the platform and that managing the transition from old system to Yammer is where the investments should be made. The Yammer article here describes their high level thoughts on the subject, key for me was the statement:

2. Start fresh with content

Our customers’ experience has shown that technical migrations of content are not generally recommended, as information on Yammer tends to be more ephemeral in nature – not necessarily needed as material for future reference. There is better potential for users to be invested in and engaged with the new network if they are empowered to shape its structure and content themselves.

The realities of Client engagements tends to be slightly less black and white, where most want to consider some form of carry across information into Yammer where they have existing knowledge management forums established. Many of our clients have established forums woven into the day to day behaviours, the information within them can’t be wilted on the vine so to speak.

One key takeaway before diving into the more detailed thoughts….

Consider why you are migrating, unless its aligned to a business benefit realisation or business goal then the effort of the migration is mis-aligned to its value to the organisation. Also consider what your new operating model is, don’t migrate an old operating behaviour along with the content, you MUST migrate the content into the new behaviours and approaches you aim to have using Yammer integrated within your organisation.

Understanding the source forum information

Whatever the technology platform involved whether it is SharePoint forums or another forum technology the key element to a successful migration is auditing and understanding the content within the current forums. Key elements to understand are as follows:

  • Users
  • Forums metadata such as Title, description and logo image
  • Security model
  • Thread content
    • Styles of thread, such as single origin, multi-thread
    • Thread parenting, which forum the earliest multi-origin thread comes from
    • Mentioning users
    • Mentioning metadata
    • Attachments
    • Links
  • Value add activities like adding additional tagging or additional metadata content

From there you need to plan the content destinations in Yammer. Not always will there be a one forum to group mapping. In fact, now may be a sensible time to ‘refactor’ the approach to segregation of the conversations to something that is more relevant or easier to understand.


The source system is unlikely to hold user accounts in the same fashion as Yammer. Therefore a mapping exercise is needed. Yammer users are keyed off the email address (the primary key as such).

A full listing of the users who have interacted with the forum needs to be generated. Alongside this a full extract of the Yammer users information should also be requested. In order to have all users within the Yammer Network you must establish the first date your network existed and pull the data from that date. The Yammer data export will only pull data where a user was interactive for that time period. This means you need to go a long way back for the first extract to get all the required user records. Subsequent users can be pulled in more recent extracts if you need to refresh and append data.

From this point you have the source and destination user lists. The next step is to produce a mapping between them. In general a good approach is to manipulate the records in the source user list to append the email address if possible. If you can get the source users to have a unique email address then you can map them directly against the Yammer user list.

From the mapping exercise you’ll be left with users in both lists who are not matched. Ignore the non-matches in Yammer side as they’re not really going to be a problem for migration as they have never interacted with the source forum. The non matched users in the source user list is where the focus should be placed. You have the following options:

  • Map all non-matched forum users to a generic account in Yammer. Something like Company Alumni, this has the advantage that it’s simple to map, and you can tie everything to one central user. During your Yammer rollout you can then inform the user base about the Alumni user and promote this as historic facts. The disadvantage of this approach is if there is value in knowing who made every thread post. Consider a situation where the discipline for the forum is more detailed and technical, users may still require to know who made which comment in order to trace that individual even outside of the organisation.
  • Map all non-matched forum users to newly created Yammer users. The advantage of this is that the user to thread relationship is maintained. Disadvantages is that you will have to consider how users are managed. If DIRSync is being performed this may be more complex. Also these users need to be active during migration and then suspended once the threads are added.

For the purposes of forum migration it is unlikely you need to consider the values within the user profiles and migrating those, but again this is worth discussing for your scenario.


Consider how you will be mapping in the existing forums. Do the existing forums contain threads which span wide topics? Could it be beneficial to split the existing forum into smaller segments, in which case the thread mapping to Yammer Groups needs to establish this. Also consider that the groups may not yet exist, so you might have to work out the creation and admin assignment as well. Be careful not to orphan any threads which are topics that no longer fit into the Yammer Group structure.

Also the big difference between Yammer Groups and many forum based technologies is that the Yammer Groups lack any form of hierarchy, so where a source forum may be grouping several sub sections the Yammer Groups don’t behave in this fashion. My thoughts here is that you should structure the Yammer Network to support the new working patterns you are creating. It is likely that the Yammer rollout is in support of other initiatives. So consider if the new Groups are topic/subject centric now, and how you might have to map threads into these topics. Many of the implementations we have been rolling out use a SharePoint site to aggregate the groups into a form of hierarchy or associations. This is a loose coupling though and a sensible approach, the association to hierarchy is only appropriate if the user scenario warrants it, such as a knowledge network.

Group metadata such as name, logo and description are also key for discovery by users within the Yammer Network. Consider also telling users which the primary language is for the group. Yammer has a pretty good translation mechanism using Bing Translate, but some groups naturally centre around a specific language.

Consider User membership for new Yammer Groups, do you want to add the users from the existing forums to the new Yammer Group? Sometimes this is a straight mapping one to one, sometimes if you re-jig the structure it becomes more complex. A simple algorithm is to capture all the users involved in the group threads and make sure they get added to the Group members. Again this in principal goes against what I’d normally be proposing, Users really shouldn’t be forcibly added to group it’s bad practice for good engagement and really annoys people.

Threads and Content

Threads and content form the cornerstone of the forum experience, in Yammer these map roughly to ‘Conversations’ and individual ‘Yams’. The Yammer paradigm is quite straight forward structure wise.

  • Network – The overall container for all the content
  • Groups – The segmentation of the content within the network into groupings of people who generate content
  • Conversation (aka a thread) – The conversations which are started and replied too
  • Yam (aka a message) – An individual post within the conversation thread.


Each thread message needs to be analysed for the following:

  • It’s parent message, so that it can be correctly associated into a new Yammer conversation
  • Any forum members mentioned in the content, so that the correct @mentions can be inserted into the new Yam
  • Any tagging used, so that the correct @mentions can be inserted into the new Yam (I know it sounds weird to say @ mentions again, but the user and tags are effectively the same with some meta data differences)
  • Any attachments being referenced by the message, so that the correct handling approach can be used (more about attachments in a minute)
  • Any Hrefs within the content, so that you can decide how to deal with the link (more about that in a few more lines)


Handling Hrefs can take a couple of formats:

  • Keep them as is and just ensure they map into the content specification of Yammer
  • Modify the url against a mapping rule set, creating a permanent redirection to other migrated content
  • Modify the url against a mapping service, creating a permanent redirection but to something that can manage the redirection as content moves around in supporting platforms

If you go for an external link redirection service consider how long this will be in place for. Consider the overall benefits of redirection and watch the analytics tracing to ensure that users are still getting benefits from the service.

I did consider using SharePoint query rules as a way to manage redirection. Imagine that you create key threads in Yammer, you can create the links within them to point to a SharePoint site, each site can have its own query rules for content promotion. So where you’re knowledge management community also has a SharePoint site collection you can implement a local collection of search schema search query rules. If you take this approach you can effectively ‘map’ a Href into a search based url with specific terms. Then it fires across to SharePoint and the relevant promoted results would be presented.


Dealing with attachments can take several forms:

  • Uploading the content into Yammer directly and effectively storing that content in Yammer
  • Making reference to external sources such as a web page where the content lives

Depending on your requirements may mean choosing the option most relevant almost on a message by message basis. My recommendation would be to store information outside of Yammer where it better aligns with collaboration systems such as Office365 sites, and upload directly where it makes more sense as social content. The obvious examples are a rule set which treats all Office document formats as upload to SharePoint and things such as images go into Yammer. You may also decide to treat some messages as ‘OpenGraph’ and have Yammer treat them as more like a notification than a message.

Thread sharing

Yammer allows a thread to be shared once created to another group. When sharing the thread sharer can choose to add additional text to the conversation share. Once shared the thread is effectively a new thread with its own content. So with this in mind you need to analyse the forum sharing paradigm in the current forums and decide how to map them into Yammer.

In situations where a thread appears across multiple forums. For example:

  • Original post goes into forum A, then is shared to forum B and C
  • When a user view either forum A,B or C the entire thread appears, thus capturing all the conversation once, but displaying it in multiple places

You need to consider how this maps into the Yammer sharing paradigm. I think the most sensible approach is to decide which Yammer Group the thread is most suited for, this is probably a manual decision in most cases. Once targeted for a specific group post the whole thread to that group, then share the complete thread into other groups. It might also be work retrospectively adding ‘tags’ to the thread.


Yammer has a tagging concept called ‘Topics’. Each thread can be tagged with topics to help discoverability. A user can elect to follow a specific Topic. So when migrating content analyse the content for potential topics and ensure they are tagged in the Yam with Topics. This is a value add activity and would require quite a lot of intelligence to identify topics in existing threads.


As you add new Yams to the Yammer threads you can’t influence the date stamp. So if you require date stamps to be known the only real solution is to append the information into the Yam text.


Always a thorny issue, the conflicting paradigms of information security and engagement and openness working like a network.

There is definitely no right answer about how to handle security, so these thoughts are where I’d propose you started.

Yammer’s paradigm really needs Yammer Groups to remain publically visible and readable to reap the benefits from working like a network. So you need to plan how to ensure information which might have been secure remains so. Often the existing forums are restricted security wise by ‘membership’ as a way to keep a tight control of who can edit, often driven by reporting and funding concerns about membership numbers rather than true data sensitivity. For this scenario in most cases adopting the public group paradigm is fine.

Where you need a private group, say for example the Board, then using a Private group is perfectly acceptable.

You will need to audit the information in every thread for its compliance if you want to be 100% sure that you’ve not shown restricted information from the existing forums in the new Yammer Groups.

User engagement and roll out

Although not strictly migration in the technical sense don’t under estimate how you need to deal with users moving them from the old world into the new. Thinking about how to help users find threads that have moved.

One possible solution to this is to add a new reply in the existing forums which contains information about the thread location within Yammer. This helps anyone who has the old thread bookmarked come away with a smile as they can navigate to the Yammer conversation and continue the discussions. It also allows for a time of dual running where some but not all threads have made it into Yammer.

Another aspect to consider is publishing the whole process for the end user to read. Sounds little bonkers at first, why should users care or be told about the internals of an IT project. Well if you think about what Yammer has as a central pillar… it’s openness. So help users get into the correct mind set.

Yammer Technical

App Registration

The processing app must be registered within Yammer. Instructions for the App Registration process can be found in the Yammer Developer Center:

Once the migration processing app is registered the Client Id and Client secret can be used by the app to make calls into the Yammer Network.


The processing app must authenticate to Yammer in order to make calls the API. Information about the authentication process and options can be found in the Yammer Developer Center:

OAuth Impersonation

To interact with the Yammer API on behalf of another user you will need to use a Verified Admin account for the processing app and have it call the relevant REST API endpoint to collect the user token for the user in question. Information about impersonation can be found in the Yammer Developer Center:


The Yammer API allows you to retrieve, create, update and suspend (soft delete) users. Information about the exact API call format can be found here:

Rate limits

The migration processing app must have logic to throttle the calls made to Yammer as to not exceed these thresholds. It should also monitor the responses and act accordingly to retry and ensure data integrity in the event of API calls being blocked. Information about the Yammer REST API rate limits can be found on the Yammer Developer Center:

The content at the time of writing is as follows:

API calls are subject to rate limiting. Exceeding any rate limits will result in all endpoints returning a status code of 429 (Too Many Requests). Rate limits are per user per app. There are four rate limits:

Autocomplete: 10 requests in 10 seconds.

Messages: 10 requests in 30 seconds.

Notifications: 10 requests in 30 seconds.

All Other Resources: 10 requests in 10 seconds.

These limits are independent e.g. in the same 30 seconds period, you could make 10 message calls and 10 notification calls


Also useful during the process is the availability of an Enterprise Yammer network, mainly so you can get the admin functions like data export and impersonation working. The question over having a discreet ‘dev’ network came up, my personal thoughts are as follows. If you’re not ‘live’ with Yammer while doing the migration work then why not simplify the moving parts by keeping just the main Network. At the end of the day you can always try things in a private group first to write your processing code, then open it up once the code is tested. Worst case you add messages you need to delete later. This keeps costs down. If however you’re already using Yammer, then best to go for multiple Networks. Again it’s your choice, but Yammer is a service that you can’t actually customise, so your options are safer in my opinion.

NB: This information is my pre-execution thinking and hopefully after the work is complete I’ll come back and make any amendments to the information.