Feingranulare Berechtigungen in Microsoft Teams und SharePoint — ohne Berechtigungschaos

Wie lösen Zugriffsprofile dieses Problem?

Die Konfiguration erfolgt einmalig im Workspace-Template. Danach erbt jeder neue Workspace automatisch die definierten Rollen und Berechtigungen.

Schritt 1: Projektrollen definieren

Der Administrator legt die Rollen fest, die im Projektalltag benötigt werden. Anders als Microsoft Teams, das Gäste implizit unter Members führt, unterscheidet Valprovia Governance explizit drei Benutzertypen:

Owners — z.B. "Projektleiter" mit Vollzugriff und "Stellvertreter" als Backup. Members — z.B. "Projektmitarbeiter" mit Bearbeitungsrechten und "Controlling Reader" mit reinem Lesezugriff. Guests — z.B. "Externer Partner" mit eingeschränktem Zugriff auf freigegebene Bereiche. Durch die explizite Trennung von Guests erhalten externe Benutzer eigene Rollen mit eigenen Berechtigungen — statt pauschal dieselben Rechte wie interne Members.

Hier legt der Administrator die Projektrollen an. Für Owners wurden "Project Manager" und "Partner" definiert, für Members der "Controlling Reader". Jede Rolle kann als Standard markiert und in der Reihenfolge angepasst werden.

Der Administrator klickt auf "New Owner Role" und gibt im Dialog den Rollennamen ein — z.B. "Projektleiter". Optional ergänzt er eine Beschreibung, die dem Endbenutzer später als Tooltip angezeigt wird.

Schritt 2: Verhalten festlegen

Zwei optionale Einstellungen steuern, wie Endbenutzer mit den Rollen arbeiten: Rollenauswahl erzwingen stellt sicher, dass jedes Projektmitglied eine Rolle bekommt — wichtig für regulierte Umgebungen und Audit-Anforderungen. Mehrfachauswahl erlauben ermöglicht es, einer Person mehrere Rollen zuzuweisen — z.B. wenn jemand gleichzeitig Projektmitarbeiter und Controlling-Verantwortlicher ist.

Schritt 3: Rollen mit SharePoint-Berechtigungen verknüpfen

Jede Rolle wird einer SharePoint-Gruppe zugeordnet. Diese Gruppen definieren, welche Berechtigungen auf welche Projektordner und Dokumentbibliotheken gelten. Falls eine Gruppe bei der Workspace-Erstellung noch nicht existiert, wird sie automatisch angelegt.

Im Bereich "Role-Based Permission Assignments" verknüpft der Administrator jede Rolle mit einer SharePoint-Gruppe. Hier ist "Project Manager" mit der gleichnamigen SharePoint-Gruppe verbunden, "Controlling Reader" mit "Project Controlling Reader". Für Gäste sind noch keine Rollen definiert.

So sieht die Zuordnung im Bearbeitungsmodus aus: Der Administrator wählt links die Rolle aus dem Dropdown und tippt rechts den SharePoint-Gruppennamen ein. Ein Klick auf den Haken speichert die Verknüpfung.

Die vollständige Konfiguration auf einen Blick: Oben ist das Workspace-Template ("ConsultancyProject.xml") hinterlegt. Darunter die Role-Based Permission Assignments — "Project Manager" und "Partner" für Owners, "Controlling Reader" für Members, jeweils mit der zugeordneten SharePoint-Gruppe. Für Guests sind noch keine Rollen definiert.

Was erleben Projektmanager und Endbenutzer?

Für den Projektmanager ändert sich der Arbeitsalltag spürbar: Statt ein IT-Ticket zu stellen und auf die Berechtigungseinrichtung zu warten, öffnet er den Workspace, fügt ein neues Teammitglied hinzu und wählt aus dem Dropdown die passende Rolle. Fertig. Die SharePoint-Berechtigungen werden im Hintergrund automatisch gesetzt.

Der Projektmanager fügt ein neues Teammitglied hinzu und öffnet das Rollen-Dropdown. Hier stehen die vom Administrator vordefinierten Rollen zur Auswahl — in diesem Fall "Project Manager" und "Partner".

Die Rolle "Project Manager." wurde ausgewählt und erscheint als Tag neben dem Benutzernamen. Der Projektmanager kann die Zuweisung noch ändern oder mit einem Klick bestätigen.

Beide Workspace-Owners haben jetzt ihre Rollen: Ein Benutzer ist "Project Manager", der andere ist "Partner". Ein Klick auf "Send request" löst die automatische Berechtigungsvergabe aus.

Nach dem Absenden erscheint die Bestätigung: Die Berechtigungsänderungen werden automatisch im Hintergrund durchgeführt. Der Projektmanager muss nichts weiter tun.

Rollen sind keine Labels — sie steuern echte Berechtigungen

Rollen-Labels an sich sind kein neues Konzept. Viele Governance-Lösungen ermöglichen es, Benutzern Tags oder Rollen zuzuweisen. Der entscheidende Unterschied: Diese Labels bleiben in der Regel rein visuell — sie beschriften einen Benutzer, haben aber keine Auswirkung auf die tatsächlichen Berechtigungen in SharePoint. Valprovia Governance geht einen Schritt weiter und verknüpft jede Rolle direkt mit einer SharePoint-Berechtigungsgruppe. Aus einem Label wird eine echte Berechtigung — automatisch, konsistent und bei jeder Änderung synchronisiert.

Ein konkretes Beispiel zeigt diesen Unterschied. Ein Benutzer hat die Rolle "Project Manager", ein anderer die Rolle "Partner":

Ausgangslage: Ein Benutzer hat die Rolle "Partner", ein anderer ist "Project Manager". Beide Rollen sind mit unterschiedlichen SharePoint-Berechtigungsgruppen verknüpft.

Als Project Manager hat der Benutzer Zugriff auf alle drei Projektordner — 01_Project Calculation, 02_Controlling und 03_Development:

In SharePoint sieht der Project Manager alle drei Projektordner. Die SharePoint-Berechtigungsgruppe "Project Manager" hat Zugriff auf die gesamte Projektstruktur.

Wird die Rolle nun auf "Partner" geändert, passt Valprovia Governance die SharePoint-Berechtigungen automatisch an:

Der Projektmanager ändert die Rolle über das Dropdown. Valprovia Governance entfernt den Benutzer aus der alten SharePoint-Berechtigungsgruppe und fügt ihn der neuen hinzu.

Das Ergebnis: Als Partner sieht der Benutzer nur noch einen Ordner — 03_Development. Die Ordner 01_Project Calculation und 02_Controlling sind nicht mehr sichtbar, weil die SharePoint-Berechtigungsgruppe "Partner" keinen Zugriff darauf hat:

Nach dem Rollenwechsel sieht der Benutzer nur noch den Ordner 03_Development. Die Berechtigungen wurden automatisch durch die dahinterstehenden SharePoint-Berechtigungsgruppen angepasst — ohne manuellen Eingriff.

Worauf Valprovia Governance den Fokus legt

Valprovia Governance versteht sich als präventive Governance-Lösung: Probleme verhindern, bevor sie entstehen. Sicherheit und Berechtigungsverwaltung stehen dabei im Zentrum — nicht nur auf Workspace-Ebene, sondern vor allem innerhalb von Workspaces: Wer darf was, und warum?

Zugriffsprofile sind Ausdruck dieses Ansatzes. Projektmanager behalten die Kontrolle über Projektberechtigungen, ohne IT-Tickets stellen zu müssen. IT-Administratoren profitieren von konsistenten Berechtigungsstrukturen über alle Workspaces und automatischer Synchronisation bei Rollenänderungen. Compliance-Verantwortliche erhalten erzwungene Rollenzuweisungen für Audit-Zwecke und automatischen Schutz vor unkontrollierten Berechtigungsänderungen. Und für Endbenutzer bleibt es ein einfaches Dropdown — sie wählen "Projektleiter" oder "Leser", und die richtigen Berechtigungen werden automatisch gesetzt.

Häufig gestellte Fragen zu Zugriffsprofilen

Wie unterscheiden sich Zugriffsprofile von den nativen Microsoft Teams-Rollen?

Microsoft Teams kennt nur zwei feste Rollen: Owner und Member. Gäste werden implizit als Members behandelt. Valprovia Governance erweitert dieses Modell auf drei explizite Benutzertypen — Owners, Members und Guests — und ermöglicht für jeden Typ beliebig viele Rollen mit eigenen SharePoint-Berechtigungen. So lässt sich z.B. ein "Projektleiter" mit Vollzugriff von einem "Controlling Reader" mit reinem Lesezugriff unterscheiden, und externe Gäste erhalten gezielt eigene Rollen statt pauschaler Member-Rechte.

Wie profitieren Organisationen mit vielen parallelen Projekten?

Die Rollen werden einmalig im Workspace-Template definiert. Jedes neue Projekt, das mit diesem Template erstellt wird, übernimmt automatisch dieselbe Berechtigungsstruktur. Bei hundert parallelen Projekten spart das hundert manuelle SharePoint-Konfigurationen — und stellt sicher, dass jedes Projekt konsistente Berechtigungen hat.

Können externe Partner und Berater eigene Rollen bekommen?

Ja, Rollen lassen sich für alle drei Benutzertypen separat definieren — auch für Gäste. So kann ein externer Beratungspartner eine andere Rolle und damit andere Berechtigungen erhalten als ein externer Auditor. Jede Rolle hat nur Zugang zu den Projektbereichen, die für sie vorgesehen sind.

Eignen sich Zugriffsprofile für regulierte Branchen mit Audit-Anforderungen?

Ja. Die Einstellung "Rollenauswahl erzwingen" stellt sicher, dass jedes Projektmitglied eine dokumentierte Rolle hat. Es kann kein Benutzer ohne Rollenzuweisung in einem Workspace existieren. Das schafft eine nachvollziehbare Berechtigungsstruktur, die bei Audits als Nachweis dient.