Be able to Nest Groups like Distribution Groups
Be able to Nest Groups like Distribution Groups. I decided to convert a lot of our team DGs to O365 groups without realizing I wouldn't be able to nest them
This would take the product to a new level. We currently have to manage two sets of groups, AD and O365 groups.
Want to know more? Simple: Organizations work in a hierarchical way, it's not new. it will remain this way.
To avoid heavy security management, we need groups embedded in one another to avoid having to add a new employee to multiple groups.
Distribution lists and security groups allow this. why not allow it in Office 365 groups?
It's a no brainer
Yes we need this feature. Can someone please update if its possible and if there is any plan to implement this?
Pablo Estrada commented
We really need this feature enabled, doing nesting reduce bunch of time-effort while administering Groups
+1. Its absolutely astounding that we can't just throw our distros in there and call it a day. We already master those off of another source onprem, and can't use this feature without being able to easily manage it some way other than thousands of manual edits.
Dros M commented
I agree, this is required. Our group memberships are already controlled locally with our HR and SIS systems. Therefore it doesn't make sense to have to then manually update groups for every group to add or remove staff or students.in our Office 365 tenant manually since we already have that automated. This could result in thousands of manual changes throughout the year not to mention significantly increasing the risk for a privacy breach if someone no longer should have access to their former groups data. This is not an efficient nor practical option.
I Completely Agree!
Oscar Stankard commented
Why on earth have they still not done this, if there's a technical reason why not why would they not say what it is? There was such a big push to get people onto 365 groups (some of my DG groups getting auto-mangled into broken 365 groups by MS at one point, don't ask…) but clearly 365 groups are designed for tiny groups in tiny organisations only? I thought this was under development years ago (baffled as I was it was initially missing) but to still find a complete vacuum of information regarding this long-promised long-overdue functionality is incredibly frustrating.
I like the functionality of 365 groups and their self-service subscription management etc, but I don't care about their associated service permissions / Yammer etc linking. If the issue is Microsoft can't work out how to extend the Exchange concept into these different systems can we not just have an option on the group for linking or otherwise with these systems? I'm sure Yammer's great, but if it being linked to a 365 group prevents me doing 'normal' things to that group it's making a simple task complex to preserve functionality I’m not using and am not interested with.
Please, please please can we have an update on Office 365 group nesting. Is it getting closer to release or is it something that's found its way to the long grass due to an irreconcilable incompatibility where it's going to stay?
Having to manually add every single member to a 365 group is an absolute time pit when you've got all the Departmental (for example) groups set up already and just want to add whole departments quickly and easily (not to mention without error). As and when a new person joins a department, working group, team or whatever it is (the main vision/purpose of a 365 group as far as I was told) you've got to add them both to that department and to all the teams that department participates in. This isn't just a doubling of work and propensity for error, it's an exponential increase. 365 Groups as it stands are not viable for large memberships or large organisations, without 3rd party tools or scripts anyway.
If we can't add groups to other groups in such an established 'normal' way (and Microsoft expect people to continue to move their currently manageable groups onto these unmanageable ones) then we need some way of automating the management of these giant flat lists. Give us a way to more easily bulk-add/bulk-remove lists of members by their other memberships/tags/custom fields etc, even if they are subsequently converted/flattened to unwieldly flat lists of individual members on the back end when you commit. And I mean a graphical out-of-the-box way; like it or not, not everyone that finds themselves responsible for an email system knows PowerShell… let alone possesses an inclination or the time to learn it just to be able to do things they considered normal before.
Nesting groups is something you've been able to do on every mail server since forever, why do I have to choose between sensible and logical (read 'normal') management of groups and the additional benefits of 365 Groups?
I seem to remember at every turn 365 was railroading me into creating everything as a 365 group and being told it would be the only option eventually anyway. Certainly during the repair of our botched auto-migration to 365 Groups (not customer initiated either, to be clear) we were told that the move to 365 groups was inevitable anyway and other group types were to be deprecated in the not too distant future. Have they now dumped this idea and will now confirm the continuation of manageable DLs?
It used to be possible to manage Exchange fairly easily out of the box without buying extra features or 3rd party tools, why does 365 need to railroad you onto such a hampered, unmanageable and seemingly incomplete feature?
Please let us know when modern groups will support such basic and established methods of management, or at least a functional equivalent.
Jaime McGeathy commented
Adding to the vote count and a comment to hopefully get this out of "tell us more" and into action. I work on an internal community program that has ~100 communities of practice. We were on DLs and are migrating to Office 365 Groups. When we need to send communications to all of our members we had a DL that had the ~100 community DLs nested into it so we just put one DL in the To line and sent our email to all 30,000 members. This type of nesting is very common in program and corporate communications. When we fully migrate to groups we'll need to put ~100 email addresses into the To line of the communication. That's error prone and inefficient.
kindly update to add one group account to another group account as a member
Microsoft always recommends us to use Office 365 Groups which replaces Distribution Lists, but it's lack of a basic feature that is add group to Office 365 Groups. :(.
Brad Welch commented
I must say, I’m very disappointed with Microsoft and their deaf ears towards its users. I am sure I read somewhere in the documentation when first deploying 365 back in oct 16 that groups could be nested in groups. But they can’t, and from an MD’s point of view, neither can any useable structure be put in place with them. O365 was meant to be easy for the end user administrator, but quite frankly it’s not. I either need to upskill for what should only be a small part of my day, or spend more money and contract the services of someone to manage. Disappointing Microsoft.
Joshua M. commented
We are also looking for distribution groups, Office 364 groups should supporting ASAP.
TELL US MORE:
Say you have 4 O365 groups: support_1@, support_2@, support_3@, and support@
support@ contains support_1
support_1 contains support_2
support_2 contains support_3
Each support_$ contains users at that support level. So emailing support_2 will email support_2 and support_3, but will not email support_1. The users in support_1 will not receive the email, nor will they be able to access it. If someone emails support, they will email the entire support team.
Likewise, Support is also a SharePoint site. It has 3 subfolders within, which are named support_1, support_2, and support_3.
The O365 group support_3 has contribute access to all 3 subfolders. support_2 has contribute to support_2 and support_1, but has read-only to the support_3 folder. Thus support_1 has contribute to support_1 folder, is able to read support_2, but does not have access to the support_3 folder.
Likewise, support@ has a dedicated support mailbox "company_support@". The only visible O365 group who has access to it is support_1, but because of the nesting support_2 and support_3 also have access to it. support_2 also has a mailbox they manage: "critical_support@" which both support_2 and support_3 have access to because of the nesting, but support_1 will not. Finally support_3 has a little shared mailbox named "escalations_support" which neither support_2 nor support_1 have access to.
escalations_support is also able to email the "sysadmins" hidden and restricted mailbox (or O365 group) - likewise, support_3 is able to email this hidden restricted mailbox/O365 group. This way, support_2 and support_1 essentially must email support_3 before escalating the issue further.
As you can see, this allows for better communication and escalation support within a company. The above was just a random example I made, but I know I for one use nested groups to help with SharePoint and shared mailbox inheritances. Without it, I have a lot of redundant work to do. Hopefully, this will give you insight of the /why/ it's needed, as well as the /what/ we mean.
James Butler commented
Is Office 365 Groups the best place to move Exchange Public Folders to? If so, then where there are a lot of nested public folders that contain emails, documents etc then moving to SharePoint isn't ideal as this doesn't handle email well so Nested Groups for Public Folder migration would make sense?
whyyyyy cant i add an o365 group as a member of a distribution group?!?!?!?!?!
Trying to drink the Office 365 Groups koolaid but can't. I need to be able to add an Office 365 Group to multiple Office 365 Distribution Groups. Not sure how O365 Groups got out of the barn w/o this feature, let alone last this long w/o it. Perhaps I'm missing a concept that avoids the need.
It would be nice to be able to nest groups and have that wizard that migrates to an office 365 group accommodate everything under that group.