SharePoint Berechtigungen
Wenn du mit Listen arbeitest, kommst du früher oder später an den Punkt, an dem du dich mit den erweiterten Berechtigungen beschäftigst. Eine der am häufigsten genutzten Einstellungen ist dabei die Einschränkung, dass Benutzer nur ihre eigenen Einträge bearbeiten dürfen. Auf den ersten Blick wirkt das sinnvoll, sauber und kontrolliert. Schließlich willst du verhindern, dass Nutzer wahllos Daten anderer verändern. In der Praxis zeigt sich aber schnell, dass genau diese Einstellung auch ihre Schattenseiten hat, besonders dann, wenn sich Strukturen ändern oder Benutzer das Unternehmen verlassen.
Und genau hier wird es interessant. Denn ohne eine durchdachte Lösung kann dir diese Konfiguration schneller Probleme verursachen, als dir lieb ist. Prozesse, die vorher stabil liefen, geraten ins Stocken, Verantwortlichkeiten sind nicht mehr klar zugeordnet und plötzlich stehst du vor der Herausforderung, bestehende Daten wieder bearbeitbar zu machen. Das Ganze ist kein Sonderfall, sondern ein absolut typisches Szenario in vielen Projekten.
Schauen wir uns kurz an, wo das Problem eigentlich entsteht. In den erweiterten Einstellungen deiner Liste gibt es unter den Item-level Permissions die Option, dass Benutzer nur die Elemente bearbeiten dürfen, die sie selbst erstellt haben. Technisch bedeutet das: Jeder sieht alle Einträge, aber bearbeiten kann sie nur der jeweilige Ersteller. Diese Logik passt perfekt für klassische Anwendungsfälle wie Ticketsysteme, Aufgabenlisten oder formularbasierte Prozesse, bei denen Verantwortlichkeiten klar getrennt sind.
Solange alle Benutzer aktiv im System arbeiten, funktioniert dieses Setup auch reibungslos. Jeder kümmert sich um seine eigenen Daten, alles ist nachvollziehbar und sauber getrennt. Doch diese Stabilität hält nur so lange, wie sich an den beteiligten Personen nichts ändert. Und genau das ist in der Realität selten der Fall.
Der Klassiker tritt ein, sobald ein Mitarbeiter das Unternehmen verlässt. Über die Zeit hat dieser Benutzer eine Vielzahl an Einträgen erzeugt, sei es in Form von Aufgaben, Freigaben, Dokumentenzuordnungen oder anderen prozessrelevanten Daten. Diese Einträge bleiben natürlich bestehen, denn sie sind oft geschäftskritisch und müssen weiterhin gepflegt werden. Das Problem ist nur: Der ursprüngliche Besitzer existiert nicht mehr im aktiven Kontext.
Durch die gesetzte Berechtigung entsteht jetzt eine unsichtbare Blockade. Die Einträge gehören weiterhin dem alten Benutzer, und neue Verantwortliche können diese nicht bearbeiten. Das führt schnell zu ganz konkreten Auswirkungen im Arbeitsalltag. Prozesse bleiben stehen, weil niemand Änderungen durchführen kann. Daten veralten, weil sie nicht aktualisiert werden dürfen. Und Workflows laufen ins Leere, weil sie auf Informationen zugreifen, die nicht mehr gepflegt werden.
Genau dieses Szenario solltest du frühzeitig im Blick haben. Denn es ist kein Ausnahmefall, sondern eher die Regel in dynamischen Organisationen. Umso wichtiger ist es, eine Lösung zu haben, die dir diese Arbeit abnimmt und dafür sorgt, dass deine Daten und Prozesse weiterhin funktionieren.
Die saubere Lösung ist ein automatisierter Ansatz, bei dem die betroffenen Einträge von einem alten Benutzer auf einen neuen übertragen werden. Genau hier kommt ein Flow ins Spiel. Du übergibst einfach die alte und die neue E-Mail-Adresse, und der Flow übernimmt den Rest. Er findet alle relevanten Einträge und aktualisiert sie entsprechend.
Das Schöne daran ist, dass dieser Ansatz nicht nur einmal funktioniert, sondern sich beliebig oft wiederverwenden lässt. Immer wenn ein Benutzerwechsel ansteht, kannst du den Flow erneut einsetzen und sparst dir jede Menge manuellen Aufwand. Gleichzeitig stellst du sicher, dass deine Prozesse stabil bleiben und deine Daten konsistent sind.
Technischer Aufbau des Flows
Der Flow ist bewusst schlank gehalten, und genau das macht ihn so effektiv. Statt unnötiger Komplexität setzt du hier auf einen klaren Ablauf, der sich leicht verstehen und vor allem gut wiederverwenden lässt. Jeder Schritt greift sauber ineinander, sodass du am Ende einen stabilen Prozess hast, der genau das tut, was er soll.Der Einstieg erfolgt über einen manuellen Trigger. Das ist in diesem Fall kein Nachteil, sondern sogar gewollt. Du willst den Flow gezielt starten, wenn ein Benutzerwechsel stattfindet, und nicht permanent im Hintergrund laufen lassen. So behältst du die Kontrolle und kannst flexibel reagieren, ohne unnötige Ressourcen zu verbrauchen.
Author/EMail eq varMailOld
Damit stellst du sicher, dass wirklich nur die Einträge geladen werden, die vom alten Benutzer erstellt wurden. Das sorgt nicht nur für eine saubere Logik, sondern ist auch entscheidend für die Performance. Gerade bei großen Listen willst du vermeiden, unnötig viele Daten zu verarbeiten, weil das deinen Flow sonst spürbar ausbremst.
Der wichtigste Teil kommt jetzt beim eigentlichen Update. Du willst das Feld Author ändern, also den ursprünglichen Ersteller eines Eintrags. Genau hier stößt du mit den Standardaktionen an Grenzen, weil es sich um ein Systemfeld handelt. Dieses lässt sich nicht ohne Weiteres überschreiben, zumindest nicht mit den üblichen Mitteln.
Die Lösung ist ein direkter HTTP Request gegen die REST API. Der verwendete Endpoint sieht so aus:
_api/web/lists/GetByTitle('Explore a List')/items(ID)/validateUpdateListItem
Der entscheidende Punkt ist hier die Methode validateUpdateListItem. Sie ermöglicht dir, auch geschützte Felder wie Author oder Editor zu aktualisieren. Ohne diesen Ansatz würdest du an genau dieser Stelle nicht weiterkommen, weil die Standardaktionen schlicht nicht ausreichen.
Damit das Ganze funktioniert, musst du den neuen Benutzer im richtigen Format übergeben. Und genau hier liegt ein Detail, das häufig übersehen wird. Der Body des Requests sieht folgendermaßen aus:
{
"formValues": [
{
"FieldName": "Author",
"FieldValue": "[{'Key':'i:0#.f|membership|varMailNew'}]"
}
],
"bNewDocumentUpdate": true
}
Das Entscheidende ist das sogenannte Claims-Format:
i:0#.f|membership|user@domain.de
Power Automate |
{
"formValues": [
{
"FieldName": "Author",
"FieldValue": "[{'Key':'i:0#.f|membership|@{variables('varMailNew')}'}]"
}
],
"bNewDocumentUpdate": true
}Wenn dieses Format nicht exakt passt, wird das Feld nicht aktualisiert. Oft bekommst du dabei nicht einmal eine klare Fehlermeldung, was die Fehlersuche unnötig schwierig macht. Genau deshalb solltest du diesen Punkt besonders im Blick behalten.
Warum ist dieser Ansatz jetzt so wertvoll? Ganz einfach: Du stellst sicher, dass deine Daten weiterhin bearbeitet werden können, auch wenn sich Benutzer ändern. Gleichzeitig verhinderst du, dass Prozesse ins Stocken geraten oder komplett ausfallen. Und weil der Flow generisch aufgebaut ist, kannst du ihn jederzeit wiederverwenden, ohne ihn neu bauen zu müssen.
Wenn du das Ganze produktiv einsetzt, kannst du den Flow problemlos erweitern. Du könntest zum Beispiel zusätzlich den Editor aktualisieren, automatische Trigger einbauen oder ein Logging ergänzen, um Änderungen nachvollziehbar zu machen. Auch ein sauberes Fehlerhandling ist sinnvoll, damit dein Flow stabil läuft, selbst wenn mal etwas nicht wie geplant funktioniert.
Am Ende hast du mit diesem Ansatz eine Lösung, die nicht nur ein konkretes Problem löst, sondern sich als wiederverwendbares Muster etabliert. Genau solche Patterns sind es, die dir im Alltag helfen, robuste und wartbare Lösungen aufzubauen.