Yammer Connected Groups
One of the features our customers want to make use of in the Office 365 suite of products is Yammer Groups with connected SharePoint sites. Each community or place would be migrated to a Yammer group with a connected SharePoint site, which would then be used to hold the migrated collaboration content. In this blog, I will cover some of the issues we have run into while integrating this functionality into the automatic migration process.
Microsoft acquired Yammer in 2012 for $1.2 billion, and in recent years they have aimed to integrate it into their Office 365 suit of products as an answer to Slack’s popularity as a communication tool used by teams. Their method of doing this is the introduction of Office 365 connected groups to Yammer. If a Yammer network is eligible, a feature can be turned on which enables the creation of Yammer groups connected to an Office 365 group and suite of products.
With this feature turned on, when a user with Office 365 group creation privileges creates a new Yammer group, an associated Office 365 group is created. A new SharePoint site, document library, OneNote notebook, and Planner are also created for the group. These products can then be accessed via the Yammer group page.
While Office 365 and SharePoint have multiple APIs to work with, the only way to access Yammer is through the Yammer REST API (https://developer.Yammer.com/docs), which at first glance, is extremely limited. The API’s main purpose, according to the documentation, is to manage group membership and messages; there are no API endpoints for group creation or management, and as you have to create a group before you can manage one, this might cause issues.
Creating Yammer Groups
There is no group API endpoint documented officially on the site, but after some testing with Fiddler and a bit of guesswork, we found the correct endpoint and data to send in the request to create a new group.
POST “https://www.Yammer.com/api/v1/groups.json“
name=[group_name]&private=[Boolean] &show_in_directory==[Boolean]
If successful, this method returns some JSON containing information about the newly created group; such as the group ID, group title and email address for the group.
This point is where we encounter our first issue; upon creation, the Yammer group connection triggers the automatic generation of a set of Office 365 applications associated with the group (Planner, OneDrive and a SharePoint site). This function runs after the Yammer Group is created as a separate background task, so no information about the associated Office 365 applications is returned via the API request.
Even after the group’s creation, retrieving the group info with a GET request, it is still not possible to get any information about the associated SharePoint site and must build the URL using the email returned in the JSON. This does not always match the SharePoint site, one example being if a site with that name already exists then the newly generated site will have a number added to the end, which the email of the group does not reflect. Currently a call is made to expected site name which checks if it exists and that our user is the owner, but if this returns false, we must manually get the site from the Yammer group before any future content load to the site.
There is another issue caused by this functionality, I already mentioned that the Yammer group creation API call doesn’t return any information about the associated SharePoint site, but this also gives no visibility of if the site was created at all. There is no error message returned if the site fails to create, so this fact would not be discovered until the task was run to validate the site names we generate from the response.
Using this same functionality during our migrations, we have seen this happen as the result of numerous issues:
- The connected group functionality of Office 365/Yammer was deactivated and this had to be reactivated by a tenant admin before we could continue with the migration.
- There is a limit on the number of connected SharePoint sites that a user can create (around 200).
- There is a 64-bit limit on the Yammer group’s title.
If any of these issues occur, the Yammer group will be successfully created, but no SharePoint site will be generated. In order to reuse the Yammer group name after the problem has been resolved, you must delete the Yammer group through an undocumented API call to remove the name from the directory, as deleting manually will not do this, and the name will remain unavailable.
DELETE “https://www.Yammer.com/api/v1/groups/[GroupId].json”
Yammer Membership
After creating the groups, the only thing we return to Yammer for is to add members to the groups. Luckily, this appears to be mostly documented in the Yammer API, and is a case of simply adding users to groups using Yammer group and user Ids.
POST https://www.Yammer.com/api/v1/group_memberships.json
data = “group_id=[GroupId]&email=[MemberId]”
Promoting a user to admin though is not documented, and again this was found using fiddler to extract the API call used when doing this manually:
POST “https://www.Yammer.com/api/v1/groups/[ GroupId]/make_admin?user_id=[MemberId]
When adding members to a group, it is expected that you will start hitting the Yammer rate limit of 10 calls per 10 seconds. When this limit is hit the response includes a 429 status code, this can be used to pause the process before retrying after the 10 seconds are up.
while added != True:
POST “https://www.Yammer.com/api/v1/groups/[ GroupId]/make_admin?user_id=[MemberId]
if status == HttpStatusCode.Created or status == HttpStatusCode.OK:
added = True
elif int(status) == 429:
time.sleep(10)
One issue we have found from adding members through the API is that while we get a successful response back, the user may not appear on the group through the front end. A user in Yammer can have one of three states, active, pending or suspended. From analysis of the migrated users in previous migrations, it appears that this issue may be caused by suspended members. It appears that a suspended member can be successfully added to a group but may not appear until their account has been un-suspended.
There is a second issue resulting from the addition of members to Yammer groups. When members are added to a Yammer group, these members should synchronise with Office 365, and appear on the membership of the SharePoint site, but for groups with larger membership this operation is not completing and a number of these users will not be carried over. There is currently a support ticket open with Microsoft about this particular content migration process.
One final undocumented API operation we found a solution for, was the deletion of members from groups. Using the same methods as before, we discovered that passing the group ID and member ID to the group membership’s endpoint with a DELETE request worked.
DELETE “https://www.Yammer.com/api/v1/group_memberships“
data = “group_id=[GroupId]&user_id=[MemberId]”
In summary, the resources for Yammer development aren’t great, the Yammer REST API is under-documented and the connect groups functionality is relatively new and barely mentioned anywhere online. But Microsoft is currently pushing Office 365 for the cloud and building out their all-encompassing Graph API, so hopefully Yammer will get some attention in the near future.
Take the next step!
A division of T-Systems, Vamosa Technologies specialises in content migration to cloud, on-premises and hybrid cloud systems. With two decades of customer migrations, Vamosa Technologies has experience with a comprehensive range of leading enterprise content management systems. To learn more about services from Vamosa Technologies, please read our case studies and whitepapers or contact us.
