Forum Discussion
SharePoint Modern Team sites Vs Communication sites
So keeping mind that guidance is just that - guidance - you need make the best choice for your customer. So here's my 2 cents on the subject and why I made the choice I did.
Communication templates do have some limitations from regular Team sites because they are meant for communication - posting documents, news, etc. They aren't intended for collaboration so I've found some list types missing, like task lists, contact lists, etc. The main reason they recommend them for hub sites is that they are trying to replicate the structure we had with subsites where the parent site was the public facing site and the subsites were the private Team/Project sites. So HR might have a communication site as the hub where they post lots of policies and links and job aids and stuff, but they would also presumably have one or more private Team sites where they work on various things internally.
There are pros and cons to the new hub/team structure vs traditional site/subsite structure for intranet. Whichever you choose, you should be aware of what you are gaining or giving up and why.
Hub/Team - is easy to arrange and rearrange with org changes by just adding/removing Team sites from the hub. Modern template sites do not have global navigation unless attached to a hub site. I think site owners have the ability to remove their sites from a hub, so be careful who you make an owner. I have seen FAR too many people who do not understand that just because the link is DISPLAYED on the navigation, does not mean people can ACCESS it or just because YOU see the link doesn't mean EVERYONE can see or access the link. An owner like that will take their Team site off the hub, and now it's out in limbo somewhere with no way for you or other users to find it. The biggest downside of this method for me is that there is no inheritance of permission groups. Access to each site has to be managed separately. Ugh
Site/subsite - As long as you use ONE parent site with lots of sibling subsites in a SINGLE layer, this can work just fine. No drill-down layers allowed - but I do fake it with navigation links. ;-) This is my choice because I (1) maintain control over who can build sites and where (2) we can leverage permission inheritance and (3) I like to keep all my options open. Yes, if there's a major reorg, you will have to migrate the content for that group. But honestly, how often does that happen relative to the day-to-day maintenance of access control lists for multiple department sites. If I have a new member of my group, I want to add them to a single member group and have them automatically get proper access to ALL the team sites they should belong to. This can only be done by using sites/subsites. Also, site owners can't move their sites into lost land. Even if they choose to remove it from the global navigation, it's still there in site contents/subsites.
Also, don't feel compelled to use modern site templates. My 800+ sites are all classic site templates. We use the modern pages and web parts by default - and honestly, you can't tell the difference except for the fact these sites have global navigation and the Teams sites don't. But if the user requires something that is only available on a classic wiki page, I can give them that if necessary. A good example is a page with a search web part that searches only one single list. I don't want it to search the entire site, just the one list. Can only be done on a wiki page which can only be built on a classic site. In a site built on the modern template, the answer is "Sorry, no can do". I like having all my options available.
So that was my choice based on our priorities. Ephemeral sites for individual projects, etc. are done through Teams at the user's discretion.
Rachel_Davis ok thanks for the long answer. but your answer is mainly comparing classic sites with modern sites (communication & team sites).. but my question is about when to use communication sites Vs Modern team sites... so i would like to keep my question focused on these points.
anyway i would like to comment on your reply (although this is not related to my original question), now all the recent official documentations from Microsoft are advising to use flat structure + modern sites, over classic sites and sub-sites. this is a case we always face in any technology, where traditional (old) structure/technologies will be replaced by newer technologies and modules. now sub-sites will still be used and have their own advantages (as the ones you mentioned), but when we want to make a long investment, and we are starting a new project (as in our case), then we need to use the technology where Microsoft will be investing more, maybe Microsoft will no longer provide any new features to classic team sites + sub-sites, and they will be enhancing the flat structure + modern sites. i am sure from one year from now the gap will be greater, also if you check the web parts currently available inside modern sites, they are more than the ones available for modern pages inside classic sites. now if you ask me why i chose to implement the flat structure for our new project, the answer simply is the future proof and where the enhancements/investment will be targeted .. and the answer will be in the flat structure + modern sites. not surprisingly if in the future we will find web parts or updates that only work when we have hub sites and sites associated with them, and that these new features will not be supported on sub-sites..
john john I think I posted to the wrong place (below)
I'm posting again. Rachel is correct. The Modern experience is more than a template change. The architecture is completely different. In the Modern experience, the architecture is flat. Each site is created as its own site collection. While Microsoft was providing an option to create a subsite, this is going away (and was never recommended). Rather than using parent/child permissions like the Classic architecture, Modern sites recognize that organizations change frequently. Each site collection is a link that can connect and disconnect from a hub easily. And, if you are a small organization, there is no requirement to have any hub at all.
I think this question is best answered when thinking about your objective. Since SharePoint Communication and Team sites store content, it is best to think about your content and permissions structure before selecting either a Modern Communication or Team Site.
Consider Content and Permissions When Choosing a Site Type
There have been several articles written explaining the Document Life Cycle. We have used these for our strategy, which is:
My Stuff - individuals save to OneDrive for Business for work that they are not ready to share (with the Team or company-wide). OneDrive for Business allows work to be shared with either read only or write permissions with individuals in or outside the company.
Team Stuff - Team Sites are created (with O365 Groups) so the team can collaborate. Anyone in the team has view and editing access to the documents. Any team wanting the additional benefit of the MS Teams application (Chats, online meetings, etc.), can easily use this application as well. In fact, we've noticed that the easiest way to create a Team site is through the Teams application. I do not believe there is a limitation on the number of team members assigned to a team site. I would strongly recommend using Teams, which has been adopted RAPIDLY by organizations around the world. It is a platform that integrates services (chat, conversations, online meetings) with other MS products as well as 3rd party vendors (Asana, Trello, Whiteboard etc.)
Everyone's Stuff - Communication sites are created to share (PUBLISH) company documents for everyone to view and use as well as for company news. There are fewer users (publishers) than there are readers.
Hub Sites Organize the Organization's Site Collections
Hub sites are easily created from existing communication sites and you can also add team sites to your hub. This gives you a shared look and feel and it is just as easy to associate a communication or team site to a hub as it is to dis-associate one. One advantage of the hub site is roll-up news from all the sites you associate with the hub (this is the default setting, but can be changed). Another advantage is that nobody can see what they aren't supposed to see. In other words, only users who have permission to see a connected Team site will see content from that site. In the Modern experience, using hub sites also provides a better search experience that is user-specific.
Much has been written above that seems to describe the former Classic architecture. In the Modern experience, subsites are NOT recommended. The hub provides the organization for each site collection that associates to it. Hubs are established (and governed) by IT. As a hub owner, you can opt to create an approval before a site (team or communication) joins. If you are a site that wants to join a hub, choose wisely because you can only join one hub. Per the September 2018 Ignite conference, having an association to more than one hub is not in the roadmap. You can, however, connect more than one hub and create a "Super Hub". We shall see...
@ OP
Did you ever find a satisfactory answer or come to your own conclusion on this? We are also dabbling with the Modern UI for a SharePoint overhaul and I just encountered the same issue where the Modern Team site has far more Web Part options than the Modern Communications site.
Most glaringly missing is the Wiki Page Library option.
Just wanted to see where this goes, not sure why Microsoft has built in so many forks and dead ends into what should really only be cosmetic template differences!
Best,
- It's more than a cosmetic template difference. Modern sites work very differently, particularly the team sites with their integration with O365 groups.
You no longer need a wiki page library. Just use modern site pages. They are just as editable by your site members as the wiki pages were, but being modern they come with responsive design and are mobile compatible which wiki pages aren't.
And while I realize that people are unlikely to intentionally navigate to your wiki page library on their phones, it's very possible (even likely) that one person might email a link to a page to another person and you have no way of knowing what device that person will use to read that email & click on that link.
I would strongly suggest you give the modern sites & pages a try. You may find you like them. I did. And I did.
