Berechtigungen für Listenelemente in SharePoint mit Power Automate verändern

Bei vielen Digitalisierungsprojekten unserer Kunden, bei denen wir bestehende Anwendungen u.a. in SharePoint umsetzen, bestehen besondere Anforderungen an Dokumentenbibliotheken oder benutzerdefinierte Listen (vgl. Microsoft List). Dabei spielt eine besondere Rechtestruktur für einzelne Dateien, Listenelemente oder Ordner oft eine wichtige Rolle.

Die Berechtigungen sollen dabei immer dynamisch und abhängig von einem Parameter des entsprechenden Listenelements oder der Datei in der Dokumentenbibliothek gesetzt werden.

Im On-Premises-Umfeld greift man für diese Anforderungen oft und gerne zu einem Provider Hosted Add-In für SharePoint und registriert dieses auf die entsprechenden Event-Typen der Liste bzw. Dokumentenbibliothek.

Mit der Verwendung von SharePoint Online kann diese Herangehensweise nach wie vor so gewählt werden, doch bietet Power Automate mit seiner Vielzahl an Standardkonnektoren mittlerweile eine breite Palette an nützlichen und umfangreichen Aktionen, mit welchen die Anforderungen der Kunden umgesetzt werden können.

Und darum soll es in diesem Beitrag auch gehen: Zunächst gehe ich in das grob skizzierte Szenario ein und zeige grundsätzlich, wie die Anforderung mit einem Provider Hosted SharePoint Add-In umgesetzt werden kann. Der Fokus wird allerdings auf der Konfiguration und Verwendung eines Power-Automate-Flows liegen, mit welchem wir diese Anforderungen mit einem geringeren Aufwand umsetzen können.

Ausgangssituation

Im gewählten Szenario besteht eine benutzerdefinierte Liste im SharePoint (Ressourcen). Die Listenelemente besitzen neben dem Titel noch einige weitere Felder vorhanden, wobei für dieses Beispiel lediglich das Feld „Verantwortlich“ relevant ist. Dieses Feld enthält Informationen zu einer Person, welche für dieses Element zuständig ist.

Nun besteht die Anforderung darin, dass nur derjenige für dieses Listenelement berechtigt wird, wer auch im Feld „Verantwortlich“ eingetragen ist. Somit sieht der jeweils angemeldete nur die Listenelemente, für welche er auch berechtigt ist.

Lösungsmöglichkeiten

Eine typische Lösung für die Ausgangssituation ist es, die Vererbung der Berechtigungen für diese Liste zu unterbrechen und eigene Berechtigungen für die jeweiligen Listenelemente zu vergeben.

Provider Hosted Add In (SharePoint)

Die Verwendung von Add Ins im SharePoint-Umfeld erscheint oft als der richtige Weg für die die Umsetzung solcher Anforderungen. Dabei bietet SharePoint neben der erwähnten Provider Hosted Add Ins auch SharePoint Hosted Add Ins. Beide unterscheiden sich jeweils im Funktionsumfang.

Für die Veränderung von Berechtigungen auf einem Listenelement oder einer Datei in einer Dokumentenbibliothek benötigt man allerdings ein Provider Hosted Add In.

Beim Deployment wird ein Teil der Applikation (App) im App-Katalog von SharePoint und ein Teil (Web) beim entsprechenden Provider (OnPrem: IIS; Cloud: z.B. Azure) bereitgestellt. Die App registriert auch die Remote Event Receiver auf der entsprechenden Liste/ Dokumentenbibliothek. Die Entwicklung von SharePoint Add Ins erfolgt in C#.

Somit ist die Verwendung sowohl für SharePoint Online als auch SharePoint On-Premises möglich.

Power Automate

Mit der Einführung von Power Automate (ehemals Microsoft Flow), begann Microsoft die Schrittweise Ablösung ihrer eigenen Workflow-Engine, welche mit SharePoint ausgeliefert wurde.

Power Automate verfolgt einen anderen Ansatz, als die bisherige Workflow-Logik von Microsoft. Hierbei verfolgt es den Low Code Ansatz. Das Ziel ist also durch die Bereitstellung von Standardfunktionalitäten in Form von Konnektoren, die entsprechenden Anforderungen zum einen komplett visuell und zum anderen mit der entsprechenden Konfiguration der Konnektoren zu realisieren.

Exemplarische Implementierung

Für die exemplarische Implementierung verwende ich eine einfache Liste, welche lediglich einen Titel (Anlagenamen) und ein weiteres Feld (Verantwortlich) besitzt, um einen Benutzer festzulegen.

In der Liste kann direkt ein Power Automate Flow erstellt werden.

Als Trigger verwenden wir den Standard SharePoint-Connector „Wenn ein Element erstellt oder geändert wird“ und definieren neben unserer SharePoint Umgebung (WFTest) auch die Liste (Ressourcen).

Zur einfachen Verwendung der PrincipalId (des Users) initialisieren wir eine neue Variable (principalId).

Anschließend soll die Vererbungsunterbrechung durchgeführt werden. Da der Trigger potentiell mehrere Ergebnisse liefert (mehrere Elemente wurden erstellt, bzw. geändert z.B. durch die Grid-Edit Funktionalität), werden die folgende Aktionen in einem ForEach ausgeführt.

Um die Vererbungsunterbrechung für unser Element durchzuführen, muss ein Http-Request gegen die SharePoint API gesendet werden. Auch hierzu besteht eine vordefinierte Aktion in Power Automate. Hierbei muss lediglich die Http-Methode und die jeweilige Uri definiert werden.

Methode: POST

Uri: _api/lists/getByTitle(‚Ressourcen‘)/items(@{items(‚ForEach_für_jedes_geänderte_erstellte_Element‘)?[‚ID‘]})/breakroleinheritance(copyRoleAssignments=false,clearSubscopes=true)

Als nächstes soll die PrincipalId des Verantwortlichen Benutzers ermittelt werden (via E-Mail). Auch dies Erfolgt über die vordefinierte Http-Request-Aktion von SharePoint.

Methode: GET

Uri: _api/web/SiteUsers/getByEmail(‚@{items(‚ForEach_für_jedes_geänderte_erstellte_Element‘)?[‚Verantwortlich‘]?[‚Email‘]}‘)

Zur einfachen Verwendung, wird die PrincipalId in der vorher initialisierten Variable gespeichert.

Wert: body(‚HTTP-Anforderung_an_SharePoint_senden:_Get_User_PrincipalId‘)[‚d‘][‚id‘]

Im letzten Schritt wird die gewünschte Berechtigung für das Element gesetzt. Dies erfolgt ebenfalls über die Http-Request-Aktion von SharePoint.

Methode: POST

Uri: _api/lists/getByTitle(‚Ressourcen‘)/Items(@{items(‚ForEach_für_jedes_geänderte_erstellte_Element‘)?[‚ID‘]})/roleassignments/addroleassignment(principalid=@{variables(‚principalId‘)},roledefid=1073741829)

Der Parameter roledefid setzt dabei die Art der Berechtigungen. Die Folgende Tabelle zeigt die weiteren Rollen-Definitionen und deren zugehörige RollenID:

Der Power Automate Flow besitzt insgesamt folgende Konnektoren:

Wenn wir nun ein neues Element in der Liste „Ressourcen“ erstellen oder ein bestehendes ändern, werden die Berechtigungen entsprechend des Benutzers im Feld „Verantwortlich“ gesetzt.

Wie im Screenshot zu erkennen, wurde im Beispiel der Verantwortliche auf meinen Kollegen Tobias Heilig festgelegt. Beim Überblick ist zu erkennen, dass der Zugriff auch für Ihn als Besitzer gesetzt wurde.

Fazit

Die exemplarische Implementierung mit Power Automate hat gezeigt, wie schnell und einfach die Berechtigung für ein Listenelement dynamisch gesetzt werden kann. Dabei wurden sämtliche Aktionen mit den Standardkonnektoren von Power Automate gelöst und umgesetzt.

Allerdings ist zu beachten, dass SharePoint zum gegenwärtigen Zeitpunkt eine technische Begrenzung besitzt, welche eine Vererbungsunterbrechung nur für 5000 Einträge zulässt, bevor die Performance der Liste merklich nachlässt [(Link)] (https://docs.microsoft.com/de-de/office365/servicedescriptions/sharepoint-online-service-description/sharepoint-online-limits#unique-security-scopes-per-list-or-library) . Auch läuft aktuell jede Aktion in Power Automate im Kontext des erstellten User. Für einen produktiven Einsatz wäre die Verwendung eines Service Users empfehlenswert.

Nichts desto weniger erhalten wir mit der Implementierung durch Power Automate eine einfach und leicht wartbare Lösung, welche sich auf andere Listen ausweiten lässt.

Mehr zur Low-Code-Lösung Microsoft Power Platform