Yammer is a private social network that helps you get connected to the right people, share information across teams, and organize around projects. Only your coworkers can join, so your communications on Yammer are secure and visible only to people within your organization. By now, Yammer is familiar to the web world, specially the corporate crowd. This article is about something which astonished me while working on a project which was about migrating legacy contents to Yammer. Must be wondering what is that which I loved so much.
The way the authentication /authorization is handled between Yammer and SharePoint, really impressed me. Microsoft’s plan to introduce something new (Yammer) without losing the relevance of the existing thing (SharePoint) is amazing. I would like to throw some light on this in detail how user permissions are handled between SharePoint and Yammer, how Office 365 comes into picture etc.., in the further part of my article. This feature is helping the new trend of having Yammer as a collaboration network with SharePoint as the resources repository.
Problem Statement:
While designing an application which involves interaction between Yammer and SharePoint, it is very important to understand the way user permissions are managed. Specially while doing a migration from some other collaboration network to Yammer and SharePoint, where to add the users to? Should I provide the users permission in only Yammer? Or only SharePoint or Yammer and SharePoint both?
If I change the permission of user in SharePoint will it reflect in Yammer or do I need to do double job of mocking the same change in Yammer too?
You will get the answers of all these once you go through this entire article.
Information about permissions handling in Yammer:
1. Private Group of Yammer:
- a. Yammer interpretation:
Let’s have a look at an example of a private group in Yammer, with 2 users, me (the creator) as owner
- b. SharePoint interpretation:
In the SharePoint end it is a group site which is Private.
- c. Permission levels in SharePoint:
Now let’s move to SharePoint and see how the user permissions as managed.
Yammer automatically creates three groups with three different permission levels (refer below picture).
By default, the owners are having Full Control as well as Edit permission.
- d. How Office 365 Exchange object is connected with Yammer:
Let’s delve deeper into each SharePoint Group created for this yammer group
DemoGroup Members
This is the user present in the DemoGroup Members, unlike as we expected to see the individual usernames here.
If we further click on the above user object, we see a federated directory object as shown below.
Wondering what kind of object is this?
Bingo, here is our Office 365 Exchange object.
- e. Office 365 – Yammer group connection
A connected yammer group has its existence in Office 365 as well. Each yammer group has a unique identifier (GUID) in Office 365, also it has an email address. The users of that yammer group are managed through an exchange list.
In our case below is the GUID (unique identifier) in Office 365 for our yammer group. If you notice the previous screenshot, the exchange object is also prepared with this GUID.
be827725-f6c1-4843-b6cc-afa01e61bca6
This Office 365 unique GUID for that particular Yammer group is a foreign key for SharePoint, Office 365 Exchange and Yammer.
A point to note here is that, only a TENANT ADMIN can access the Office 365 exchange.
- f. How to manage permissions of Yammer group using Office 365 Exchange.
Below are the details of the exchange group for “DemoGroup”
The yammer group has an email id (exchange mailbox address). It shows my name (the creator) as the owner. Similarly, the members are also displayed in an editable list box
If you can see above, the users are managed from this exchange object for the connected Yammer groups.
If we add or remove any member /user from the Office 365 Exchange, it reflects in both SharePoint and Yammer, the same way if we change users in Yammer it reflects in other two places.
But we cannot tamper anything from the SharePoint end. SharePoint is only the recipient here. Also, if we notice the “DemoGroup Owners” group in SharePoint even the exchange group is not shown there, whereas if we do a check permission, we can see that the owner is having Full Control privileges.
My interpretation of this is that Microsoft gives full control of managing the permission of a group only and only to Yammer, not to SharePoint. But of course, the tenant admin can change the permissions from the Office 365 Exchange interface.
Demo of the above explanation:
Let’s try doing the user changes from Exchange, let add one more owner “Arup Kumar Maity” from the exchange. Want to see how it reflects in Yammer?
Yammer
SharePoint:
Don’t you think I showed the same type of screen shot earlier in this article as well?
Yes, you are right, there is no change in the user permissions from the SharePoint display perspective, whereas at the Yammer end we can see the new member. Who manages all these? All these are managed by the Office 365 Exchange object for that Yammer group.
What if I add a user in SharePoint in one of the groups (owner/member):
Even if we add any user to that SharePoint group, it won’t reflect in yammer, that user will have only privileges to access the SharePoint domain, but not is corresponding Yammer domain. It is a very important point one should understand while deciding a project architecture.
This is all about a Private Yammer group. The overall picture of the user’s permissions flow can be depicted as below.
2. Public group of Yammer:
I think I have explained a lot about a private yammer group. Hope SharePoint and Yammer is not getting overflowed from the brain. Just a lighter note.
All the above holds good for a public yammer group as well. But there is a slight change in case of a Yammer connected Public group.
Just that an extra member is added for a public group “Everyone except external users” under the members group in SharePoint.
Office 365 Exchange interpretation:
Let’s have a look at the exchange group for this public yammer group. You know what this group “Everyone except external users” is only locally added in SharePoint and will not be available in the exchange group. In SharePoint domain, this allows any user to access or have Edit privileges in SharePoint and Yammer domain, as this is for public contribution so open to all.
Conclusion with Solution:
Hope this article is helpful to you in deciding the architecture model of any new project which involves Yammer and SharePoint.Below are the case scenarios which I could evaluate after understanding the way users are managed between Yammer/SharePoint/Office 365 exchange.
|
Use Case |
Yammer Permission |
SharePoint Permission |
|
Connected Yammer Group as an entry point to the user |
User add/delete into Yammer OR Office 365 using UI or API |
NA |
|
SharePoint as a document repository with users with Yammer intervention |
NA |
Users who need not be part of Yammer |
|
Disconnected Yammer Group as a an entry point to the user |
User add/delete into only and only Yammer using UI or API |
No SharePoint site in case of disconnected Yammer groups, hence no question of managing users in SharePoint. |
