Why should I create a communication site, while I can also publish the pages in the Teams site?

[tom_s1865]

Hello,

Can you please help me clarify why should I create a communication site while I can have same webparts/features of com sites to a team site? 

Thanks,

[#2]

Hi,
Could you be more specific about your question? By the way, you are right: you can create pages in both kind of sites

[#3]

If I can create pages in team site which seems to be having more features than communication site, then why one would ever go for creating a site with communication template? I would rather create team site always. What is the purpose of the communication site if everything of communication site is possible in team site?

[#4]

Because you might no need a MS365 Group, you want to prevent users to create also an associated Team, recycle bin can be hidden making if more appalling for a site to be used only for publishing information.

[#5 · Accepted solution]

@tom_s1865 

A team site is meant to collaborate in, so all members of the site create content and have more or less the same permissions, but access to this site is typically limited to few people. You can even easily share content externally. To make collaboration easier, you automatically get an M365 Group, a shared Mailbox and all the stuff @Barbarur mentioned.

A communication site is meant to be open to a large part of, if not your whole organization. A few content authors create content, but a but a larger number of people consume that content. If you provision a communication site, then you just get the site, nothing else. (So no M365 Group.)

In terms of things like available webparts, team sites have more webparts. As a team site has a group, so you get some webparts that make only sense on a site with a connected M365 Group like a "Planner Webpart".

The following webparts are only available on a team site

• Asana
• Bitbucket (and Bitbucket Server)
• GitHub (and GitHub Enterprise)
• Google Analytics
• Incoming Webhook
• JIRA
• Office 365 Connectors
• Planner
• RSS
• Salesforce
• Stack Overflow
• Trello
• UserVoice

On the other hand, if you want to use some other features that are usefull if you build an intranet, then you need your site to be a communication site.

An example is the "Home Site". This needs to be a communication site.

If you narrow your view down to a single site then a team site has more features that a communication site and you would not really need a communication site template.

But team sites are preconfigured for collaboration and come with M365 groups and some other settings build in. These make team sites difficult to use if you i.e. want to create an intranet that contains hundreds of sites.
Then you would have hundreds of M365 Groups that you either don't use at all or that you would need to keep synchronized with the same users.

With communication sites you would just add the same "Active Directory Group" to the "Visitors SharePoint Group" of every site to achieve the same effect.

So if you view at all of your sites  in a tenant at one, communication sites take less ressources and are easier to handle in the cases where you don't need all the collaboration features.

Best Regards,

Sven

[#6]

Thank you very much @SvenSieverding  and @jcgonzalezmartin  for your responses with detailing. Appreciate

My concern is, Currently in dept. let's say HR, There is a communication site and some team site -- at present none of the sites are associated with hub structure.

My goal is to reduce having more sites for a single dept. in the organization having many dept under various units.

So I think, instead of having communication site as a hub and other teams site to be associated with that hub, why not having a team site registered as a hub itself? Our need is any way to display pages on the landing page based on managed properties filtration which would work on team site landing page too - so rather than having just a dedicated hub to display pages on landing page, I can have a dedicated "Team Site" as a hub which is created via Microsoft teams?

Do you think that is a viable option?

(Idea is we want to get rid of multiple sites for single division and create confusion around it)

[#7]

Hi @tom_s1865,

You are speaking of a huge problem in every modern intranet.

There are so many channels and sites and users don't know where to post what.

But my experience is that it is not the number of sites that confuses people, but two other things.

First are logical errors in the navigation to the content (so people don't find content where they are expecting it) and second are insecurities and fears ("Am I editing the wrong page? Who is going to see  my updates?")

I think that a department normally has at least two requirements concerning communication. On the one hand the department members need a space to collaborate and work in. That space is typically not accessible by people from other departments. On the other hand a departments needs a plattform to tell the rest of the company what it is doing and to provide documents etc. 

I tend to give each of these requirements an own site to keep the structure and the needed permissions of every site extremely simple. So following the upper example I create a team site with an M365 group and add all department members to that group. They can use that site to collaborate internally. Then I create a communication site that is visible to all members of the company, but only editable to all members of the M365 group of the team site. 

Then I make bóth sites visibly different, give them catchy names (so that it is instantly clear to the members, on which site they are on and what that site is for) and create a working navigation.

I also provide trainings and teach the users what to put where. Sometimes I even "patrol" these sites and try to find content that is not where it should be. Then I tell the creator where the content belongs and offer additional training.

Sometimes I create even more sites for a single department. For example could it be a good idea for an HR Department to create a site that only contains "Work Instructions" instead of having them in a document library on the main, public facing HR site (But have that "work instructions" site linked from the main HR site). This is kind of like a "work instruction" database and you also have the opportunity to "enhance" the user experience with additional metadata pages and documents. That can make them easier to find.

This also makes very easy to teach your users which content to put where: "Do you have a work instruction? Put it in the work instruction site." (So, don't think in organizational hierarchy but in tasks and workflows)

You can put all that into a single team site, but you still have to deal with the requirements.
That means that you have to create more complicated permissions and site structures on that team site and that in my experience leads to more problems than having multiple sites. And if in the future that organizational team needs to be restructured, then it could be a horror de-assemble that single team site you crammed everything in. (This is much easier with multiple sites)

But the most important thing about having a single site or multiple sites for a department is:

Neither alone solves the problem that your users don't find content or are unsure where to put their content.

You can only solve that with a good, consistent navigation, user training and a good governance.

Best Regards,
Sven