Hidden membership groups - should members be hidden from eachother, too?


We're wondering if there is demand for a group with membership hidden from members _and_ non-members alike. One possible scenario is an enrichment group for employees, where the company doesn't want the employees to be able to easilly capture and then distribute a list of its top talent, but progresive discovery among the members through email and file sharing is OK/desired. 


Do you need this type of group today - what for? If so, how do you meet this scenario today? 


For reference, our current implementation of hidden membership hides the member list from non-members, but members can see eachother. The design acknowledges progressive disclosure would happen in an active group, and it's harder for members to collaborate when they don't understand the size/membership. 



13 Replies

Hi Eric, thanks for reaching out. Yes, I've been asked this by customers and there is a need for certain scenarios as you say. If one could be able to hide the list of members it would be great, of course any interaction done by any member should be visible - so it's like an opt-in thing if you want to be visible.

Thanks @Wictor Wilen! How do these customers accomplish this task today? 

I think that it is OK for members in a group to be able to view each other. As you note, if the group is active, people will realize who is in it because they see the names on conversations and documents. I think there are more pressing issues to be solved before you get into the edge condition of the 0.02% of hidden groups where members need to remain secret from each other.

They don't :) But they would like to.

Just wondering if this has this been implemented yet? We need to be able to hide member lists from members within the same group. We are a school district, and some of our classes are Special Ed in nature. If a parent of a Special Ed student is assisting their child with Office 365 applications, then the parent would be able to see a list of the other Special Ed students in his/her child's class. 

This is a much desired feature for us, as any connection to our organization is by default categorized as sensitive information. As a volunteer organization we want to give some of users access to create and/or manage their own groups and let them add guest users to share emails and files with. However, membership in these groups does not entail the right to know the identity of the other members.


Today we work around this by using distribution lists, which is sub optimal as group owners can only add existing external contacts. without giving them too much admin access. These request are handled by central office by the system admin and two recipient admin.

@Eric Zenz 

Hi Eric,

Are there any updates on this one? We are looking to have Yammer as a student communication space for a program we run at USQ, but need the member list to be hidden. Progressive discovery through sharing is okay.



We are looking for this feature as well for large groups within the school where we don't want a member to have access to the names of every one member of the group.  @Eric Zenz 

Yes we really could use this for student support service at our college.

We need to send documents to all our learners, that they can fill in and we can monitor progress. Teams Assignments is ideal for this, as Teams is heavily used now across college (due to the pandemic!) and all staff and students are familiar with it.

But putting all our supported students in one group where they can see who else has support needs is unacceptable for data protection reasons.


@Eric Zenz At the University of Washington, our central Groups Service supports membership privacy, where if enabled, you can specify which identities can view the membership. This design approach goes well beyond what you've asked. We can support this design in Active Directory, but not in Azure AD, due to the lack of attribute based access control features. I've personally been asking the Identity team for this type of support for over 5 years now, and if you talk to Vince, I'm sure he has me on his backlog list.


In terms of use cases where this type of functionality is used, there are many. The most common is course groups, where many nationalities have regulatory requirement to keep student records private, and of course, which courses you take is part of that student record. In the US, FERPA guidelines do recognize that others in a course can/will know by physical presence who else is in a course. Other common examples include all the employees who work in a physical building, where safety is often the driving factor for privacy (think disgruntled violence and locating a person). These scenarios also come with knowing who else is in your building. Within our medical center, there are other regulatory reasons for private membership, and those use cases should not expose membership to other members.


Brian Arkills

@Eric Zenz 

I believe the ideal scenario would be some sort of Role-based access.

For example let say company has multiple branches and senior managers and top leaders would have access to all groups and branches but new employees and interns would only need to access people in their own group or those who are working for them. 

It would be interesting , if we could set like each person could only see members in their own groups and special permission to access member from other group.

For example, for new employees or temporary contractors, it is not recommended to have access to everyone in the entire company (even through Global Contact) and this access should be granted per group or/and per user.

There should be some pre-defined compliance rule too, so if someone with lower position regularly searching for key people in the company or top manager, it might be either internal risk or something is wrong in the department and the employee want to voice out and this is something needed to be monitored in the audit and compliance like trend of search based on positions and person with respect to privacy.

@Eric Zenz Yes, we have use cases which require Groups where the members can't see other members. They are essentially using the Group as a mailing list. We can't use distribution lists as we need to include externals. The requirement comes down to GDPR, not sharing email addresses around.

@Eric Zenz we also have this requirement for GDPR/privacy reasons, e.g. for BAME and LGBT networks. It's also frustrating that the existing "hiddenmembership" option only works when you create a new group and no longer works using the set-unifiedgroup cmdlet.