Welchen Seitentyp wann?

Was sind Vor- und Nachteile von Team- und Kommunikationswebseiten in SharePoint Online?

Neulich wurde mir die Frage gestellt, warum es in SharePoint denn zwei Seitentypen gibt.

Beim Erstellen einer neuen Seite haben wir die Auswahl zwischen den beiden Seitentypen Teamseite und Kommunikationswebseite. Die beiden Seiten unterscheiden sich auf den ersten Blick nur darin, dass bei der einen die Navigation auf der linken Seite ist und bei der anderen auf der oberen. Auf den zweiten Blick scheint es dann so zu sein, dass ich mit einer Teamseite inhaltlich alles machen könnte, was ich auch mit einer Kommunikationswebseite machen kann.

Also, warum und wofür brauche ich dann diese beiden Seitentypen?

Eine Teamseite ist dafür gedacht, dass du darin mit anderen zusammenarbeiten kannst. Anders ausgedrückt erstellen alle Mitglieder der Site gemeinsam Content und haben dabei mehr oder weniger dieselben Rechte. Du kannst auch recht einfach Dateien mit externen Benutzern teilen. Um die Zusammenarbeit über das Teilen von Dateien hinaus noch einfacher zu machen, wird dir bei Erstellung einer Teamseite automatisch eine M365 Gruppe und ein Teampostfach im Exchange erstellt.

Den Content auf einer Kommunikationswebseite sollte für eine größere Gruppe von Usern, wenn nicht sogar die gesamte Organisation relevant und sichtbar sein. Hier erstellt eine kleinere Gruppe von Autoren Content und eine große Anzahl von Personen konsumiert ihn. Wenn du eine Kommunikationswebseite erstellst, dann bekommst du auch nur diese Site, sonst nicht (also bekommst du keine O365 Gruppe)

In Bezug auf verfügbare Funktionen und Webparts sind auf der Teamseite mehr Webparts verfügbar. Das vor allen Dingen daran, dass wir bei einer Teamseite eine M365 Gruppe zur Verfügung steht. Daher machen manche dieser Webparts auch nur hier Sinn.

Die folgenden Webparts sind nur auf einer Teamseite, aber nicht auf einer Kommunikationswebseite verfügbar

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

Falls Du aber ein Intranet bauen und etwa Features wie eine Homesite nutzen willst, dann muss diese Seite eine Kommunikationswebseite sein.

Das bedeutet nun alles das Folgende:

Wenn du jetzt also deinen Fokus nur auf eine einzelne Seite legst, dann hat eine Teamseite mehr Features als eine Kommunikationswebseite. In dem Sinne bräuchtest du nie Kommunikationswebseiten.

Aber:

Teamseiten sind stark für die direkte Zusammenarbeit angepasst und kommen, wie oben schon erwähnt, fest verwoben mit einer M365 Gruppe und anderen Einstellungen. Diese machen eine Teamseite aber schwieriger zu nutzen, wenn du beispielsweise ein Intranet aufbauen möchtest, das aus potenziell hunderten von Seiten besteht. Dann müsstest du nämlich entweder all diese M365 Gruppen mit häufig denselben Berechtigungen synchron halten oder du würdest die Gruppen zugunsten einer anderen Berechtigungslösung gar nicht benutzen. In dem Fall sind die Gruppen nicht nützlich und in der Übersicht sogar eher hinderlich.

Bei einer Kommunikationsseite würdest du einfach eine neue Active Directory Gruppe erstellen und die in den "Besucher" Gruppen auf jeder neuen Intranet Seite hinzufügen. Das ist von der Verwaltung her wesentlich einfacher.

Wenn du nun also statt auf eine einzelne Seite deinen Fokus auf deinen gesamten Tenant legst, dann nehmen Kommunikationswebseiten weniger Ressourcen in Anspruch und sind einfacher zu handhaben.

Insbesondere wenn ich zu einem gegebenen Anwendungsfall keine Zusammenarbeitsfeatures benötige, wähle ich daher meistens eine Kommunikationswebseite statt einer Teamseite.

Hat dir das gefallen? Vielleicht magst du auch...

Die versteckte SharePoint Benutzerinformationsliste

In einer versteckten Liste speichert SharePoint Informationen über Benutzer

SharePoint Json List Formatting und die nicht existierende WEEKDAY Funktion

Es gibt keine Funktion beim JSON List Formatting, mit der sich der Wochentag berechnen lässt. Man kann ihn aber selbst berechnen.

Quick Tip: Eine Communication Site als Subsite anlegen

Man kann über die UI keine Communication Site als Subsite anlegen. Per Powershell geht es aber problemlos.