Embedding Yammer threads into SharePoint pages

Recently I was asked:

Can you tell me if it is possible to embed a specific conversation in a site? I’ve tried every combination on the “Open Graph” possible to get a specific conversation thread to embed. I can’t seem to figure it out. And I’ve read your blog post and I don’t think you answer that here.

Questions like this one arise as ‘Threads’ are not exposed through the Yammer Embed widget or mentioned in the embed documentation. Hacking at some embed code to change the ‘Feed type’ to ‘thread’ and the ‘Feed ID’ to the ‘threadId’ of the specific conversation would be the logical approach. Alas this does not work. If you are a developer and fancy rolling up your sleeves there is a REST API item for threads but you’ll need to handle and style the resulting JSON payload which feels like too much work.

My recommended approach is to use Topics as they can be easily applied and surfaced in an embed feed. Topics themselves are a relatively undocumented feature but are immensely useful. For example we have their use embedded in our business process.

mm use case

I digress, let’s get back to the answering the question.

When using topics to embed a specific thread I recommend that you use the threadId as the topic label as that saves you from inventing a word that describes the thread. Topics are also useful as you can then easily aggregate threads together at a later date.

  1. Obtain the threadId
    • Locate the thread you wish to embed
    • Selecting the date is a quick way of getting to the thread and its Id
    • Grab the threadId of the thread from the address bar
    • The URL of the thread in the address bar will be something like: https://www.yammer.com/yournetwork.com/#/Threads/show?threadId=751952638. You need the last part e.g. 751952638
  2. Add the threadId as a Topic label.
    • Threads are a view of a single conversation
    • Select the first message in the thread and add the threadId as a topic label
  3. Get the feedId of the Topic label
  4. Use the feedId in your embed code (remember to set the ‘Feed type’ to ‘topic’)



Yammer and Teams – better together for communities and knowledge

I firmly believe that Yammer and Teams are complementary products. As an example, consider our situation.

How we use Yammer

We use Yammer as the focal point for our 80 or so communities of interest aka Practices. These communities represent the combined knowledge and talent of the 16,000 staff at Mott MacDonald. Those communities can be large, with in excess of 1000 members, whilst others are small. Every community is treated equally as their common goal is to open opportunities through connected thinking. Within these communities, we see three collaborative patterns:

#1 Communities work out loud

The community works out loud sharing their hopes, fears, aspirations and knowledge in the Yammer Group. They make the most of serendipitous discovery. i.e. the ‘classic’ Yammer use case. They use an associated SharePoint site to manage their content which in turns enables wider discovery through Search and Delve.

#2 They form teams to get things done

Teams form within the community that focus upon particular ideas, topics, activities or events. More often than not they need somewhere to meet, work and converse away from the main community. As their work progresses they share progress back into the main community until finally they are ready to publish the results of their efforts. Sometimes these teams are incubators for new communities and we allow them to undergo their own virtual Darwinism with the survivors emerging as new communities. For events, the group responsible need to establish communications streams and areas to share that allow them to focus upon preparation and delivery of the event.

#3 They govern as a network

We require that each community be supported by a small team – typically a pairing of senior influencers and emerging stars. Their role is to coordinate, manage and cajole the activities of the community. Each team feeds into a network of Champions and an overarching Board of Group Sector Leaders responsible for the entire community ecosystem. The teams, champions and board need somewhere to occasionally work, say to plan a new initiative, meet, or develop reports but most of their time is spent within the communities themselves.

It works but could benefit from improvement…

Before the arrival of Teams and Yammer integrated Office 365 Groups we would have catered for patterns 2 and 3 through a hotch potch of spaces. Some teams would use separate Yammer groups, others combinations of SharePoint and Yammer or a mixture of collaboration over email with a SharePoint site or someone’s OneDrive for the content. None of the modes has been particularly productive or effective. Though it has been a struggle to put a finger on why. Perhaps this was down to a shift in the style of the conversations (to faster, more clipped, less formal), a shift in the team dynamic, reduction in size or the dilution through distribution of the content and conversations.

Capitalising on teams

The arrival of Teams gives us the opportunity to take a different approach

#1 Using Teams to support community governance

We could form a single private Team for the management of the communities. Privacy is considered important for this team for operational reasons but we will encourage them to be more open. Using a Team has the advantage that it is easy to switch from being private to public. In the Team, we could create a Channel per community to act as dividers for the content and conversations but with 80+ to look after coupled with low volumes content and conversation we might not need to be that granular. In fact, clustering the teams together into sectors would be more likely and easier to adopt. We could form a channel for the Champions and one for the overarching Board. In doing so we would reserve the General channel for any other business. By placing the management teams, Champions and Board into one large Team they should find it easier to share experiences, coordinate activities and become more cohesive as a unit. The shared OneNote with a section per Channel will help establish divisions (where required) and they can use it for their meeting notes, knowledge capture etc.

#2 Using Teams to bolster teamwork

On demand, we will form a public Team per community to host the team. If the activity is particularly detailed we may even create a Team for that specific purpose. Each team will be given a Channel and members can take advantage of the awareness features like the publishing of Team Meetings and group calling to stay in touch and keep up to date with other related items or areas (teams) of interest. The awareness features and shared permission model will help to reinforce the binding through the community. The simplicity of the SharePoint site associated with the Team will help people focus on the work in progress. In turn this will serve to reinforce the position of both the communities SharePoint site and our global Document Centre as the repositories for approved, published knowledge and information. This will allow the communities to review and augment content at the most appropriate time with structured metadata to enhance its discovery.

#3 Connected communities and teams

We will add to each Team a tab that displays the associated Yammer Group for the community. This is possible using the website tab option and adding the URL to the Yammer Group. (It would be easier if Yammer was one of the published tabs). This will provide Team members with an easy way of pushing information into and pulling from the Yammer Group as well as keeping them in touch with wider conversations. Similarly we will include a SharePoint Document Library tab that links to the Yammer Groups SharePoint site. Finally we will wire up the Yammer Connector to push both announcements and relevant topics into the conversations. An added benefit for those normally trapped in Outlook is that they could then use the Team app as their ‘single pane of glass’ into the communities which will help them transition away from closed email centric collaboration.

We will continue to use Yammer for the communities and in doing so use Yammer in the way it is intended. It also overcomes two key sticking points:

  1. the scale issue faced by Teams as a team is limited to no more than 999 members.
    • By being consistent with our architecture our staff should find it easier to understand the “how” and “why”.
  2. the need to share the Office 365 Group identity between the Team and Yammer.
    • By using the connectors and tabs we overcome the invisibility of the Team’s Office 365 Group to Yammer and it also neatly focuses the team on not competing with Yammer.

Overheads will remain

Introducing Teams will generate an overhead three manual requirements to:

  1. manage the membership of the Team
    • We will look to link up our dynamic groups service which is driven from staff profiles in Delve.
  2. manually add Yammer as a tab and set up the connector
  3. persevere with the currently sub-optimal push-pull of content from the Yammer Groups associated SharePoint site
    • The possibilities for management, push-pull etc. will improve with the third wave of Yammer’s integration with Office 365 Groups. At that point we will look to upgrade the Yammer Group to a connected Office 365 Group, adjust the membership mechanism to use the Office 365 Group identity etc. In doing so we might need to conduct a one-off migration from the existing SharePoint site to the new connected site as this would reduce friction around the push-pull and user experience.

Yammer and Teams – better together

Through combining Yammer and Teams we should be able to form a neat constellation of communities and supporting teams that connect our thinking.


(I’m sure there is a more artistic way to represent this. A management ‘Team’ as the Sun at centre, orbited by a ring of Yammer Communities, each with a moon or several moons of ‘Teams’ and it’s SharePoint site.)



I’m not “Doughboy”, I’m a real person (and it’s not Yammer’s fault)

There have been several threads emerging regarding missing profile images in the Office 365 Suite Bar (example thread). The problem seems to centre around the fact that, whilst users add their picture to Office 365, it fails to appear when using services like Yammer or Planner.

To illustrate:


Based on the code, my picture is being obtained using the email variable from:


It’s the same in Yammer. In fact it’s using the same chunk of code.

Planner (Suite Bar)

Hmm… I’m “Doughboy” in Planner yet my avatar just below the Suite Bar shows me.

Planner (Avatar)

Interestingly the code is obtaining my avatar from a different location to the one used by SharePoint and Yammer:

Power BI

From watching the page load using Edge Developer tools, it’s my interpretation that Power BI is obtaining my picture from another location:

Office 365 Home

Finally, I’m “Doughboy” in Office 365 Home. 😦


To me the appearance of “Doughboy” and variable end points is a sign that there is an inconsistency in the Suite Bar wiring.

In some of the threads on the subject, Yammer has unfairly taken the blame for the appearance of “Doughboy”. I believe it is not a Yammer issue and it is all about the wiring behind the scenes. In addition to the examples at the start of my post I’ve seen other mismatches – my current profile image in Office 2016 Apps, with the exception of Outlook, is different to the one in the Office 365 Suite Bar *but* Office 365 ProPlus should be wired up via Azure AD.

Word 2016
Outlook 2016

I guess to some of you reading this you might be wondering why the fuss in the first place, it’s just a picture after all. My argument is that we all readily identify with our own image. Its appearance shows that this is our instance of SharePoint, or Yammer post. It helps us, probably at a subconscious level, to make a personal connection. It also seems a feature of human nature that little inconsistencies, especially in our appearance, can really make us question what is going on. When we are trying to get people to adopt Office 365 we tell them about the behind the scenes magic that wires content to people, people to content and it is a consistent experience on any device, anytime, anywhere. Variability in the profile picture, and the presentation of the Suite Bar for that matter, undermines the consistency point and leads people to question the wiring.

In producing this post, I conducted some research into how it should work. The Suite Bar *should* be getting your profile picture from the Office 365 Directory Service, which in turn goes out to Exchange Online to get it, as that is where the image is stored when you upload it [1]. Once in Exchange, your image is pushed down to SharePoint for use there [2]. SharePoint can use one of three renditions of the image based on the component that needs it. The examples from the start of my post show that the services then call differing end points which in turn *should* all lead back to the image in Exchange Online.

In the case of Yammer, it gets its profile information from the Office 365 Directory Service but it only takes the User items [3] e.g. Name. Avatars work in Yammer, whilst perhaps “Doughboy” might be in Suite Bar as:

“If a user’s Yammer profile does not include a picture, the profile will be updated with the user’s Office 365 profile picture. This update is initiated when the user logs in to Yammer and will be reflected in the Yammer profile within few hours. If the user later updates his or her Office 365 profile picture, the Yammer profile picture will also update after the user logs into Yammer.” [4]

As a side note, I’d definitely raise a support ticket with Microsoft if your Yammer avatars do not have pictures. In this situation, something is blocking the pull down of the Office 365 profile picture. It could be something as simple as deleting profile images in Yammer, waiting a few hours and it should push them back down but best if Microsoft look into it for you.

In my opinion the current architecture does not make sense as your profile image should sit outside Exchange Online or SharePoint Online i.e. treated like the other core Active Directory properties and independent of the service that consumes it. I understand that changes would need to occur if Active Directory where to be used as there is anecdotal evidence of a 100kB file limit. Great for avatars rubbish for Delve, Skype etc. where high definition images are required. Hence SharePoint has a 5MB limit and another end point for those images. Having a single endpoint would help developers and companies who do not want to lead with Exchange Online first etc.

I hope Microsoft can review and revise the wiring.

[1] The image is stored in Exchange – https://support.office.com/en-us/article/Add-your-user-photo-to-Office-365-2eaf93fd-b3f1-43b9-9cdc-bdcd548435b7 – It can be manipulated by the Set-UserPhoto (which is an Exchange commandlet). It is also why (regrettably) people still need to lead with Exchange Online, or at least license users for it, if they want the most cohesive onboarding experience into the other workloads. Without an Exchange Online license, there is no Exchange account to hold the profile picture. This can be worked around for SharePoint by uploading images directly into its User Profile Service.[back to article]

[2] I’m not aware that the actual sync interval is published by Microsoft but authors of articles like this one https://spbreed.wordpress.com/2015/11/06/demystifying-user-profile-picture-sync-in-office365/ go into the details of the inner workings. In SharePoint, images can be stored in – https://msdn.microsoft.com/en-us/library/office/microsoft.sharepoint.client.userprofiles.peoplemanager.setmyprofilepicture.aspx [back to article]

[3] This article has a useful table with the attributes passed through to the various services in Office 365. For Yammer (see the Third Party section) https://docs.microsoft.com/en-gb/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized [back to article]

[4] Taken from the FAQ in this article https://support.office.com/en-us/article/Manage-Yammer-users-across-their-life-cycle-from-Office-365-6c4c8fff-6444-404a-bffc-f9da0bcc3039 [back to article]

The Office 365 Network is born

Ensure that every escape route and exit is still clearly visible when the lights go out

I know some of you use the Yammer Office 365 Network to seek answers and to discover new knowledge. Microsoft, in their infinite wisdom, have decided to close that network. The closure is described in this article: Announcing the public preview of the new Office 365 Network online community . It is being replaced with a new publically accessible forum Office 365 Network . The forum is not built on Yammer and its usability is questionable at best though they do say they are working on that…

This is not a vote of no confidence in Yammer or a #yamexit. It is Yammer’s strength that has forced this move. By design, Yammer is not publically indexable by the likes of Google and Bing. The lack of unauthenticated discovery allows people to converse and collaborate in confidence, safe in the knowledge that their contributions will not surface in unexpected locations, be used out of context etc. There are those in Microsoft who feel that the lack of discoverability through search by non-authenticated users is a barrier that needs to be removed.

The shift to a new publically accessible platform will cause a change in the conversational dynamics. Whilst the platform is not intended for ‘break-fix’, they still want people to use the likes of Microsoft | Community (aka Microsoft Answers) for that, it is built on forum technology which, by design, lends itself to Q&A rather than collaborative discussion. Only time will tell if Microsoft manage to keep a lid on the ‘break-fix’ and are able to foster a sense of community. Another change in this area is that Microsoft will control the creation of groups. Inevitably this will keep the focus on the products rather than the wider issues and thinking that directly influences the usage and adoption of the products.

The platform also includes gamification and you can expect to be awarded badges for almost every action. Some will find this immensely irritating and others will revel in it. The value gamification brings to building a community is questionable but it’s one of the hooks Microsoft feel they need to get people to take part.

The question remains ‘how does this affect you?’

  • You have between now and the 1st of September to make the move to the new network
  • Conversations in the new network are public and you have reduced control over any content you share
  • Any member of your staff can participate, they do not need a work account (this has benefits as well as risks)
  • It’s up to you to preserve or migrate content from the Yammer Office 365 Network. Any knowledge that you wish to retain after 1st September needs to be copied out and be aware that Microsoft will not be providing tools to help you
  • The vast majority of groups will not be migrated so if you have one for collaboration, say with your Microsoft account team or a group of like minded individuals, you’ll need to find a new home for those conversations.
    • Now could be the time to switch on external access for Yammer in your home network and invite your partners to join you there
  • You should consider communicating to staff the presence of the new network and what it is intended to be used for. You could use the opportunity to reinforce desired behaviours e.g.
    • something is broken – raise a ticket
    • want something changed – raise a request
    • not sure or want to ask – use a Group in your own Yammer network
    • have something broken on a personal device – use answers.microsoft.com
    • want to request a new feature (in a Microsoft product) – use UserVoice : Customer Feedback for Microsoft Office 365
    • want to take part in the product conversations – use Office 365 Network

You may be interested in the perspectives of others on this subject:


It will be interesting to watch how this venture unfolds.

Quote and sign credited to Seton and in particular their Luminous Exit and Path Marker Signs – Door Exit Route (Right)


The perfect serve of Yammer?

Recently, I’ve been wondering whether Yammer is being developed like ‘medicine’ or ‘Coca Cola’? I’ve been typing, deleting, typing, deleting and in the process I’ve started to challenge my own thinking. I feel that I’m going a little crazy with the thought process so I felt I’d throw the concepts out there.

  • Medicine – developed through thousands of hours of research and testing. Typically, highly consistent product that should only be consumed in the way it is intended.
  • Coca Cola – developed to a level of product consistency such that each one tastes the same wherever it is consumed but it can be consumed in a multitude of ways. You don’t find ice cream floating in medicine, or use it as cooking liquor to make a ham but you can still taste the Coke in both.

My thinking is that Yammer is not medicine which you have to consume as per the instructions. Yammer makes helpful suggestions in how it should be consumed, just like a Coke bottle has best served cold on it. Items like the Discovery feed are just that, helpful suggestions to how it should be consumed. Intended to guide you to an outcome.

Yammer is part of an ecosystem that is founded upon choice and interconnectivity. The risk is that Yammer ignores the choice and interconnectivity and positions itself as medicine. For example, connectors or shared storage using OneDrive would help with the choice and interconnectivity and just like Coke they will enable Yammer to be consumed in a multitude of ways. Conversely if Yammer where medicine you’d be forced to consume it in the browser or app with a propriety file management solution.

Then again Coca-Cola did start out as medicine


It’s not an Oscar but…

Just over 3-years ago I finished my last construction project. The construction market was deep in recession and I was struggling to see where the next opportunity would come from. I faced a choice, one faced by many of my colleagues, the choice to “stick or twist”. Some of my colleagues chose to “twist”, dusting off their CV’s and striking out for roles, typically outside of the industry. My choice was to “stick”, well at least with the same company, as there where opportunities if I was willing to move outside of construction. I took a gamble with a six-month secondment into our internal IT service.

For me, IT was a gamble as all of my formal training is in construction and engineering. I gambled on having some transferable skills coupled with a passing interest in technology. I felt that I offered great value as I could help the service with my experience in how colleagues actually used the technology provided to them. I’ve always had a passing interest in technology and I’ve tried to include it in my construction projects whenever I could – from the early days of installing the foundations to the Reading Room at the British Museum to the digital models used in my last project.

As it happened it took a while for me to understand which of my skills where actually transferrable. I extended my secondment several times before settling in my current role. It’s in this role where I have finally realised which skills are actually transferrable. It’s also this role that’s led to a moment of real pride. In fact, its generated the same satisfaction that I used to get when I walked around a completed construction project.

About 18-months ago, the decision was made to rollout Office 365. My role was to use my business knowledge to shape the solutions that we would provide through Office 365. One thing led to another and I found myself becoming deeply immersed in the product and the solutions. I even started to describe myself as a fledgling Enterprise Architect in my LinkedIn profile. I found skills that I learned from construction, like the ability to take a holistic view and the value of a good specification, helped me assimilate and understand the complexity and depth of Office 365. Similarly, there are parallels between how construction projects run and how IT deliver projects. On a construction site, the team would meet daily to discuss the tasks to be completed. The meetings would not have a name but typically the team would gather around the project plan or a set of drawings and work through the days and weeks ahead focussing upon the items to be built in the period. In IT, Developers do the same thing but call it a ‘daily stand-up’ and describe the process of focusing on the items to be built in a period as ‘Agile’.

In the last 12-months, I’ve become both architect and evangelist. I attribute a lot of my success to my involvement in the Office 365 Network. It’s through this network that I’ve been able to accelerate my learning, deepen my knowledge and crucially make contacts and friends with people who are on a similar journey. The Office 365 Network is built on a product called Yammer and I’ve taken to Yammer like a duck to water. Perhaps there is something in Yammer that appeals to the engineer in me and it certainly clicks with my personality type.

Unbeknownst to me, my contributions to the Office 365 Network had been spotted by staff in Microsoft. I suddenly became aware when a notification landed in my inbox just before Christmas. I had been nominated for consideration as a Microsoft Most Valuable Professional (MVP):

The Microsoft MVP Award is an annual award that recognises exceptional technology community leaders worldwide who actively share their high quality, real world expertise with users and Microsoft. All of us at Microsoft recognise and appreciate Simon’s extraordinary contributions.

I was flabbergasted and humbled by the nomination. To be perfectly honest I expected nothing to come of it. There are only around 4,000 MVP’s in the world and most have worked in the industry for years building up their knowledge, networks and reputation. I felt that I did not fit the mould. However, the emails kept coming from Microsoft and today one landed with the subject:

“Congratulations 2016 Microsoft MVP!”


Tonight I’m proud, engineer proud. 🙂


Triaging Yammer Embed

Yammer Embed should work but there are times when you could end up chasing your tail trying to understand why it does not work. This is especially true if you are new to using Embed. So I thought I’d put a post together that describes my triaging process when things go wrong.

Start from something that works!

Now I know it seems simplistic but the embed code is *code* and by its very nature sensitive to typo’s. Hence I recommend using the widget to generate code especially if you are new to it.

When triaging problem, I recommend starting with the Yammer Widget as it allows you to test Embed whilst ruling out SharePoint and other gremlins. It’s a relatively straight forward fill in the blanks exercise. I’d start with simply setting the Widget to display your home network. As shown below:

widget example


If you cannot get the Widget to work, then it is likely that you have either browser or network related problems. In the case of your browser make sure you are using a supported browser e.g. Internet Explorer 11. If you are using an unsupported browser (refer to the ‘Browser and system requirements’ section), then you can expect a degraded or non-existent Yammer experience. Yammer contains code that identifies the type of browser and modifies the Yammer experience accordingly e.g.

yammer ie9 example



If it is not the browser and the widget fails to work, then I’d start suspecting either a Service Outage (which you should be aware of as these are posted in the Office 365 Admin Centre) or a configuration issue with your network. Later in this post I describe a couple of methods for confirming the basic configuration of your network.

Use the code from the widget

Assuming that you can get the widget to work, the next step is to reuse the widget code in a SharePoint page. For this you need a page in your environment that is ‘straight out of the box’. By this I mean it does not have additional styling or code as you might find in an Intranet page. The reason for using a basic page is to rule out any issues like JavaScript or CSS clashes. I use the code from widget as it will be error free. A common mistake when hand coding embed script is to miss off a comma and a missing comma can be hard to spot!

In order to perform this test, you’ll need the code from the widget which has been topped and tailed with some additional code to tell SharePoint where to get the Yammer JavaScript file from and that it is code to be executed. If you need a point of reference for this take a look at the basic example at the top of my earlier blog post about using Yammer Embed.

I would conduct this test using a Content Editor Web Part (CEWP) and not a Script Editor Web Part (SEWP). Using a CEWP means that you can vary the code without losing access to the page you are testing it in! Trust me it is super annoying to paste some flaky code into a SEWP for you to lose access to the page and have to roll a version back (if you have versions enabled!) or worse still delete the page and start again.

You should be able to get the basic code to work and from there you can start testing in the target environment e.g. an Intranet page. If that fails, then you have a SharePoint configuration or code security problem.

Check your SharePoint configuration

I’ve only used SharePoint 2013 and SharePoint Online and Embed works fine in both environments. I have read reports from users of SharePoint 2010 that Embed can fail in that environment. In some cases, this is down to SharePoint rendering the page in such a way that the browser switches to a compatibility mode which is lower than the supported mode.

Another potential blocker to Embed working is whether third party code is allowed to execute in your SharePoint environment. At this point it would be worth following my network configuration checks before pointing your finger at your SharePoint Administrator!

Check your network

Network configurations and firewalls can introduce a level of variability and complexity that can seem daunting. However, there are some really simple steps that you can perform prior to involving your network administrator.

I’d start by checking that you can access:


You can do this test by pasting the address above into the address bar in your browser. The result should be that your browser will attempt to download a file:

yammer code


If that fails, then there is either a Browser trust issue or more likely your firewall is getting in the way. In this context I use the term ‘firewall’ quite loosely. The file could be blocked by your firewall, it could be intercepted by your anti-virus application, a proxy service might be getting in the way etcetera etcetera. If the JavaScript code cannot be loaded the Yammer Embed part will not work! It would be odd if you can get the Widget to work but not be able to download the file.


Go back to basics

If you’ve read this far and are still struggling to get Embed to work, then perhaps you need to take a big step backwards and get your network administrator to confirm that the basics required to get Yammer to work are also in place. This might seem odd, especially as you’ll no doubt be able to access Yammer through your browser but some networks are tightly nailed down. Microsoft recommend that to successfully use Yammer a number of addresses and rules are allowed through your network and firewalls. Some administrators do not like opening up all of the recommend connections and so it’s worth double checking that they have. As a point of reference the firewall and trust rules are detailed here https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2#BKMK_Yammer . It’s worth them also checking the SharePoint requirements (listed on the same page several sections above the yammer ones).

As I mentioned earlier it might also be worthwhile talking with your SharePoint Administrator as they might have configured SharePoint to prevent the execution of code etc. If all else fails raise a support ticket with Microsoft.



Using Yammer Embed in SharePoint Online

One of the use cases for Yammer Embed is to provide a commenting system for SharePoint pages. This can be achieved using the Yammer Embed Open Graph method. It is possible to generate the necessary code for this using the Yammer Widget (which is my preferred way as you can test the options as you go) or code from scratch using the published documentation. An example code snippet is shown below:

<script type="text/javascript" src="https://c64.assets-yammer.com/assets/platform_embed.js"></script>

<div id="embedded-feed" style="height:500px;width:500px;"></div>

 container: '#embedded-feed'
 , network: 'your_network_name.com'
 , feedType: 'open-graph'
 , config: {
 header: false
 , footer: false
 , showOpenGraphPreview: false
 , promptText: "Comment on this page"
 , defaultGroupId: 4191007

I recommend playing with the Yammer Widget to test the configuration options.

Using Yammer SSO and Yammer DSync?

If you are using Yammer SSO and Yammer DSync in your environment then you will need to adjust your code by adding the use_sso: true element to the configuration section. You will also need to be very aware that Yammer SSO and Yammer DSync are being deprecated and will stop working after December 1st, 2016. You will not be able to set up new configurations with Yammer SSO and DSync after April 1st, 2016. An example code snippet is shown below:

<script type="text/javascript" src="https://c64.assets-yammer.com/assets/platform_embed.js"></script>

<div id="embedded-feed" style="height:500px;width:500px;"></div>

 container: '#embedded-feed'
 , network: 'your_network_name.com'
 , feedType: 'open-graph'
 , config: {
 use_sso: true
 , header: false
 , footer: false
 , showOpenGraphPreview: false
 , promptText: "Comment on this page"
 , defaultGroupId: 4191007
 "objectProperties": {
 "url": location.href,
 "description" : " Comments feed for page ",
 "title": document.title + " (captured with document.title)",
 "image": "https://mottmac.sharepoint.com/sandpit/Documents/CompassIcon_100.jpg",
 "type": "page",

Adding the code to SharePoint Online

There are a couple of options for adding the embed code to SharePoint Online and I’ll cover them in detail in another post. If you wish to test out your code, simply paste it into a Script Editor Web Part. The result will look something like this:basic commentsCreating a comment using the feed will send details of the page to Yammer which would then create a specific Yammer page to hold the comments. The result in Yammer will be:

basic page in yammer
In my opinion, the outcome is less than optimal and to understand why we need to go behind the scenes.

What is happening behind the scenes

When you post using Yammer Embed, it attempts to resolve information about the SharePoint page using a behind the scenes Yammer service (which was previously Embed.ly.) It then uses this information to set items like the name of the page in Yammer and the descriptive text. However, this service does not have the ability to resolve metadata from a page that requires authentication to access, is located behind a firewall etc. This inability includes pages in SharePoint Online as they are located behind an exterior ‘Sign in to Office 365’ sign-in page. When the service attempts to resolve information, the ‘Sign in to Office 365’ page gets in the way. The result is the incomplete capture of information and pages in Yammer sharing the Title ‘Sign in to Office 365’ and Descriptive text ‘It looks like you are on a slow connection. We’ve disabled some images to speed things up…’. Each page is unique as it uses the URL from the SharePoint page but the experience is sub-optimal, for example, searching for a particular page will result in many identical search results.

A solution

The solution is to include the information Yammer needs to help the service resolve the page information. This is achieved using objectProperties in the Embed code. Unfortunately, you cannot use the Yammer Widget for this – though I hope in the future they can provide some common examples. In the case of SharePoint, you will also need to know some SharePoint properties so you may need to enlist the help of your friendly developer. The method is to add a section to the Embed code that provides the Open Graph metadata for consumption by Yammer (which in turn it will use to create the page). An example code snippet is shown below:

<script type="text/javascript" src="https://c64.assets-yammer.com/assets/platform_embed.js"></script>

<div id="embedded-feed" style="height:500px;width:500px;"></div>

 container: '#embedded-feed'
 , network: 'your_network_name.com'
 , feedType: 'open-graph'
 , config: {
 header: false
 , footer: false
 , showOpenGraphPreview: false
 , promptText: "Comment on this page"
 , defaultGroupId: 4191007
 "objectProperties": {
 "url": location.href,
 "description" : " Comments feed for page ",
 "title": document.title + " (captured with document.title)",
 "image": "https://your_sharepoint.com/sandpit/Documents/CompassIcon_100.jpg",
 "type": "page",

Note the comma that has been added at the end of Line#16. The code will fail if the comma is omitted. The result in SharePoint will look something like this:

feed in SPO after

With the corresponding page in Yammer:

feed in yammer

What the code is doing

The purpose of each item in the snippet is as follows:
[Line #18] “url”: location.href this sets the URL property used in the Yammer page to that of the Page in SharePoint. (location.href is a SharePoint property)
[Line #19] “description” : ” Comments feed for page “ this sets the description text that will appear on the Yammer page. In this example I have used text but you can use a SharePoint page property, for example if you are using a Byline property in the page or use a combination of property and text (see next item for an example).
[Line #20] “title”: document.title + ” (captured with document.title)” This sets the Yammer page title to that of the SharePoint page and appends an additional snippet of text to the title. A potential gotcha with this is if you change the Title of the SharePoint page after it is created. The Title field will use the original name unless you edit it. (I’ll cover changing this in another post.) As with other items you could use a different SharePoint page property to populate this item. (document.title is a SharePoint property)
[Line #21] “image”: https://your_sharepoint.com/sandpit/Documents/CompassIcon_100.jpg This sets the image shown in the page header of the Yammer page (very much like a Group icon). In this example I have set it to use our Intranet icon.
[Line #22] [ “type”: “page” ] This tells Yammer that the object is a page. If you were using this solution say for Office 365 Video you might set this to “video”.

Wrap up

And there you have it, a way of using Yammer Embed in SharePoint Online. In future posts I’ll cover methods of managing instances of Yammer Embed in SharePoint Online as well as items like renaming of SharePoint pages.