06-28-2017 09:04 AM
06-28-2017 09:08 AMSolution
When you create a new Communication site, we don't create a new Office 365 Group. But you can add 1-n existing Groups to the membership roles for the site. We expect that people have team sites and groups where they collaborate, and Comm sites are meant to have a relatively smaller set of editors and a large amount of readers
06-28-2017 09:14 AM
we think the membership model is going to be an asset to customers, as it gives the flexibility of different roles in SharePoint and you can also add different group entitires, including Office 365 Groups. Look forward to your feedback as you use it
12-04-2017 12:26 PM
As the SharePoint Service Administrator for our tenant, where do I go to find all of the Communication sites? I don't see them listed in the SharePoint Admin > Site Collections panel. And since O365 Groups are not created for Communication sites, I don't see them in the Admin > Groups > Groups panel.
01-31-2018 08:18 AM
Hey @Andy Haon, "selling" modern team sites next to communication sites comes fairly natural as "evolutions". Still the combination of bugs with the modern UI while manipulating security elements, and the fact the Modern team sites (connected to office 365 groups) versus Communication sites have a different behaviour when it comes to security is quite a blocker to adoption.
It is expected for the Site owners to understand the differences and impact in either case. Consolidating this approach towards using "Role" approach versus the classical "membership" should be the way forward.
01-31-2018 09:50 PM
While it's not currently possible to see the list of modern Communication Sites in the current tenant admin experience, it will be possible to see and manage them in the new tenant admin experience we debuted this past September at the Ignite Conference. You can register for a limited preview of that new experience here:
Additionally, you can see the list of Communication Sites in your tenant via Powershell. Details here:
Hope this helps!
01-31-2018 10:30 PM
02-01-2018 10:39 AM
Marius - can you explain a bit more about what you see as an adoption blocker for Communication sites, specifically as it relates to the differences between them and Modern Team Sites? We love this kind of feedback.
02-02-2018 03:38 AM - edited 02-02-2018 03:44 AM
Permissions model in SharePoint has been a major issue for participants, since like forever. Version after version got more comprehensive - and ultimatelly UI hasn't really keep up. At least until modern UI came, which moved towards our major user base - the End user (call it Power User L1, L2 or Site Owner, etc. - still the End User that requires fairly advanced training to feel confortable). Add the "Share" into the mix, which breaks inheritance, plus the External Sharing with variations on how resolution work, as compared with "members" - you get the image. Every serious organisation has also some kind of mechanism in place to control proliferation of groups in AAD, ranging from naming conventions down to who can create and expiration.
The good news - at least at 1st, was the arrival of Office 365 groups as the "membership service" which combined with UI improvements moved the debate from dealing with "membership" towards a "role" model - which to be honest is definitelly more scalable. Hence, talking about "Reader role" was easier to "sell" as business people do NOT care about what is a group (be it SharePoint or AAD, or Office 365 Group).
BUT... the UI is still lack some things (e.g. inconsistence in using "AAD groups" only for members) but also buggy as items are not reflected the same depending on whether you use SharePoint UI versus Outlook Groups UI, plus it delivers by default way too much permissions to so-called "Members" via the newly introduced "EDIT" permissions level - that should be rapidly corrected. Hope @Christophe Fiessinger can hear and help with these topics (unless a User Voice suggestion already pointed this out).
..and back to Communication sites - both "modern", agree with different purposes, but people expect same experience for common tasks - e.g. classification labels missing, and again bloody security, which is reverting to the something similar to Classical model. So someone participating in either, e.g. as Owner, needs to understand the differences to operate it succesfully. Now add the need to provision consistent workspace structures (using PnP in this case) and of course the security must be tackled diferently in the code.
End-users are confused as to how to better keep control, different everytime. Consolidating experiences should be your target no.1 or otherwise same issues we had while trying to clear out "Publishing sites vs. Team Sites" will be again the main topic, but only far more complicated, because "Classical sites are here to stay" (which personally i think should be at least discouraged -too many options clouds people choices).
04-04-2019 02:37 PM
04-04-2019 02:37 PM