Digitale Vorgangsakte in SharePoint: Einen belastbaren Freigabeprozess mit Power Automate bauen

Viele Freigaben sehen digital aus und sind trotzdem Handarbeit.

Der Antrag kommt per E-Mail. Ein Anhang liegt irgendwo im Postfach. Die Rückfrage läuft in Teams. Die Entscheidung steht in einer weiteren Mail. Drei Wochen später fragt jemand: „Wie ist eigentlich der Stand?“

Dann beginnt die Suche.

Das Problem ist nicht, dass eine Schaltfläche fehlt. Das Problem ist: Der Prozess hat keinen gemeinsamen Zustand.

In dieser Anleitung bauen wir deshalb nicht einfach einen hübschen Flow. Wir bauen eine kleine digitale Vorgangsakte:

SharePoint hält Vorgang, Status und Dokumente zusammen.
Power Automate steuert Prüfung und Freigabe.
Teams oder Outlook informieren die Beteiligten.
Die Entscheidung bleibt am Vorgang nachvollziehbar.
Copilot kommt erst später dazu – als Wissensschicht, nicht als Ersatz für Prozesslogik.

Als Beispiel nutzen wir eine Beschaffungsanfrage. Das ist konkret genug für eine echte Genehmigungslogik: Bedarf, Kostenstelle, Betrag, gewünschter Termin und verantwortliche Freigabe.

Erst die unangenehme Wahrheit: Ein Flow repariert keinen unklaren Prozess

Bevor ihr Power Automate öffnet, müsst ihr sechs Fragen beantworten können:

Was startet den Vorgang?
Welche Angaben sind zwingend notwendig?
Wer darf beantragen?
Wer entscheidet nach welcher Regel?
Was passiert bei Rückfrage, Ablehnung oder Zeitüberschreitung?
Wer verantwortet den Prozess nach dem Go-live?

Wenn der Fachbereich diese Fragen nicht beantworten kann, automatisiert ihr keine Arbeit. Ihr gießt Unklarheit in Technik.

Für unsere Beschaffungsanfrage lautet das Minimalmodell:

Ein Mitarbeiter legt einen Bedarf an.
Der Antrag enthält Kostenstelle, Kategorie, Begründung, Betrag und Wunschtermin.
Eine benannte Rolle prüft den Antrag.
Die Entscheidung lautet „Genehmigt“, „Abgelehnt“ oder „Rückfrage“.
Antragsteller und Prozessverantwortliche sehen jederzeit den aktuellen Stand.
Jede Entscheidung wird mit Zeitpunkt und Kommentar gespeichert.

Die konkrete Freigabematrix hängt von eurem Unternehmen ab. Betragsgrenzen oder Rollen dürft ihr nicht aus einem Tutorial übernehmen. Sie gehören in eine fachlich abgestimmte Regel.

Die Architektur: Vier Bausteine, eine Wahrheit

Für einen kleinen, nachvollziehbaren Prozess reicht oft dieses Muster:

SharePoint-Liste „Beschaffungsanfragen"
        ↓ neuer Vorgang
Power Automate
        ↓ Validierung und Freigabe
Approvals + Teams/Outlook
        ↓ Entscheidung
SharePoint-Status und Entscheidungsprotokoll

Microsoft dokumentiert sowohl Freigaben auf Basis von SharePoint-Listen als auch dokumentbezogene Freigaben aus Bibliotheken.[4][5] Entscheidend ist nicht, welches Template ihr anklickt. Entscheidend ist, wo der verbindliche Status liegt.

Unsere Regel:

SharePoint ist die Vorgangsakte. E-Mail und Teams sind Benachrichtigungskanäle – nicht die Datenbank.

Liste oder Dokumentbibliothek?

Nutzt eine Liste, wenn der Vorgang im Mittelpunkt steht: Antrag, Status, Zuständigkeit, Frist, Entscheidung.

Nutzt eine Dokumentbibliothek, wenn ein Dokument selbst den Prozessgegenstand bildet: Vertrag, Rechnung, Angebot oder Richtlinie.

In vielen realen Szenarien braucht ihr beides:

Liste für den Vorgang
Bibliothek für die zugehörigen Dokumente
eine eindeutige Vorgangsnummer als Verbindung

So müsst ihr keine sensiblen oder großen Anhänge in einer endlosen Liste verstecken und könnt trotzdem jeden Vorgang vollständig nachvollziehen.

Schritt 1: Das Datenmodell in SharePoint bauen

Erstellt eine SharePoint-Liste „Beschaffungsanfragen“ mit mindestens diesen Spalten:

Spalte	Typ	Zweck
Titel	Text	kurze Bezeichnung des Bedarfs
Vorgangsnummer	Text	eindeutige Referenz, zum Beispiel `BA-2026-0042`
Antragsteller	Person	verantwortliche Person
Kostenstelle	Auswahl oder verwaltete Metadaten	fachliche Zuordnung
Kategorie	Auswahl	Hardware, Software, Dienstleistung, Sonstiges
Betrag	Währung	Grundlage für die abgestimmte Freigaberegel
Benötigt bis	Datum	Priorisierung und Eskalation
Begründung	Mehrzeiliger Text	fachlicher Kontext
Status	Auswahl	Entwurf, Eingereicht, In Prüfung, Rückfrage, Genehmigt, Abgelehnt, Fehler
Zuständiger Genehmiger	Person	aktuell verantwortliche Rolle
Entscheidungskommentar	Mehrzeiliger Text	nachvollziehbare Begründung
Entschieden am	Datum/Uhrzeit	Audit-Trail
Flow-Korrelation	Text	technische Nachverfolgung

Warum so viele Statuswerte?

Weil „Offen“ nicht reicht.

Ein Vorgang mit fehlenden Angaben ist etwas anderes als ein Vorgang, der auf die Entscheidung der Einkaufsleitung wartet. Und ein technischer Fehler darf nicht wie eine fachliche Ablehnung aussehen.

Rückfrage und Fehler brauchen deshalb eigene Zustände:

Rückfrage = der Prozess läuft, aber der Fachkontext fehlt.
Fehler = die Automatisierung konnte ihren Schritt nicht zuverlässig ausführen.

Diese Trennung spart euch später Diskussionen und macht Support überhaupt erst möglich.

Schritt 2: Ansichten für Menschen bauen – nicht nur für den Flow

Eine Liste ist noch kein Arbeitsbereich. Erst sinnvolle Ansichten machen sie im Alltag nutzbar.

Erstellt mindestens:

Meine Anfragen – gefiltert auf den aktuellen Nutzer
Zur Freigabe – Status „In Prüfung“, gefiltert auf den zuständigen Genehmiger
Rückfragen – alle Vorgänge, die auf Ergänzung warten
Überfällig – benötigtes Datum überschritten, Entscheidung noch offen
Abgeschlossen – genehmigt oder abgelehnt
Technische Fehler – Status „Fehler“, nur für Process Owner oder Support

Wichtig: Eine SharePoint-Ansicht ist keine Zugriffskontrolle. Filter wie „Meine Anfragen“ oder „Zur Freigabe“ steuern nur die Darstellung. Wer einen Vorgang wirklich lesen oder ändern darf, muss separat über Site-, Listen-/Bibliotheks- und – wenn fachlich erforderlich – Elementberechtigungen geregelt und mit Testidentitäten geprüft werden.

Plant vor dem Bau mindestens diesen Berechtigungsvertrag und ersetzt die Beispielwerte durch euer tatsächliches Rollenmodell:

Rolle/Identität	Site	Vorgangsliste und Listenelement	Dokumentbibliothek und Dokument	Konfigurationsliste	Sharing und externe Links	Flow/Connection
Antragstellende	Site-Zugriff nur für die Anwendung	eigene Vorgänge lesen; nur vor Einreichung definierte Eingabefelder ändern	nur eigene verknüpfte Dokumente gemäß Lebenszyklus	kein Zugriff	keine direkte Freigabe; externe Links standardmäßig aus	keine Flow- oder Connection-Rechte
Genehmigende	Site-Zugriff für zugewiesene Aufgabe	nur zugewiesene Elemente lesen; ausschließlich definierte Entscheidungsfelder ändern	zugehörige Dokumente lesen, wenn fachlich erforderlich	kein Zugriff	keine Weiterfreigabe; Ausnahmen nur nach dokumentierter Genehmigung	keine Flow- oder Connection-Rechte
Process Owner	nach dokumentierter fachlicher Regel	definierter fachlicher Gesamtzugriff; sicherheitsrelevante Felder nur im geregelten Prozess	nach fachlicher Regel lesen	lesen; Änderungen nur im Change-Prozess	Links und Direktfreigaben regelmäßig prüfen	Run-History lesen; keine implizite Credential-Nutzung
Support/Betrieb	zeitlich und fachlich begrenzter Supportzugriff	nur für dokumentierten Supportfall lesen/bearbeiten	nur für dokumentierten Supportfall	normalerweise lesen	keine eigenständige externe Freigabe	Monitoring/Recovery gemäß Betriebsauftrag
Plattformadministration	technische Administration	technische Administration, nicht automatisch fachliche Bearbeitung	technische Administration	nach Administrationsauftrag	Tenant-/Site-Regeln administrieren, nicht fachlich freigeben	Verbindungen administrieren, aber nicht als fachliche Identität nutzen
Flow-/Service-Identität	kein interaktiver Benutzerzugriff	nur erforderliche Elemente/Felder lesen und schreiben; keine freie Änderung von Genehmiger, Owner oder Sicherheitsmerkmalen	nur erforderliche Dateien lesen/schreiben	ausschließlich lesen	darf keine Sharing-Links oder Direktfreigaben erzeugen	dedizierte Connection Reference; Least Privilege; Credential-Lebenszyklus dokumentiert

Direkte Freigaben und externe Links sind standardmäßig deaktiviert. Jede Ausnahme braucht Owner, Zweck, Ablaufdatum und Genehmigung. Eine Flow-Identität darf nicht mehr Rechte besitzen als der automatisierte Schritt benötigt und keine sicherheitsrelevanten Felder aus unvalidiertem Input übernehmen.

Testmatrix für effektive Rechte

Zugriffspfad	Positivtest	Negativtest
UI/Ansicht	berechtigte Rolle sieht nur erwartete Vorgänge und Aktionen	ausgeblendete Ansicht oder Schaltfläche darf keinen unberechtigten Zugriff kaschieren
Direktlink	berechtigte Identität öffnet das konkrete Listenelement oder Dokument	nicht berechtigte Identität erhält weder Element noch Metadaten
Suche	berechtigte Inhalte erscheinen entsprechend den effektiven Rechten	nicht berechtigte Vorgänge und Dokumente erscheinen nicht in Treffern oder Vorschauen
API/Connector	Flow-/Service-Identität liest und ändert nur freigegebene Ressourcen und Felder	fremde Elemente, Konfiguration, Sharing und sicherheitsrelevante Feldmanipulation werden abgewiesen

Führt jeden Test mit mindestens einer berechtigten und einer nicht berechtigten synthetischen Identität für Site, Liste, Listenelement, Bibliothek, Dokument und Konfigurationsliste aus. Dokumentiert zusätzlich die effektiven Rechte der Flow-/Connection-Identität. Verlasst euch nicht darauf, dass ein ausgeblendeter View, ein Link oder eine Power-App-Oberfläche den Direktzugriff verhindert. Dieses Template ist kein Nachweis für einen konkreten Tenant; die Testprotokolle bleiben ein separates Go-live-Gate.

Damit beantwortet SharePoint die wichtigsten Alltagsfragen ohne E-Mail-Suche:

Was wartet auf mich?
Wo fehlt eine Information?
Was droht zu spät zu werden?
Was wurde entschieden?

Schritt 3: Den Flow als Zustandsmaschine denken

Der Flow startet, wenn ein Antrag eingereicht wird. Verwendet nicht jede kleine Feldänderung als Startsignal. Sonst baut ihr schnell Schleifen, doppelte Genehmigungen oder schwer erklärbare Zustände.

Ein belastbarer Ablauf sieht so aus:

3.1 Trigger eingrenzen

Start nur bei einem neuen eingereichten Vorgang oder einem klaren Statuswechsel
Trigger Conditions nutzen, wenn der Flow sonst bei jeder Änderung laufen würde.[9]
Vorgangsnummer und Korrelation früh setzen

3.2 Pflichtdaten validieren

Prüft vor der Freigabe:

Kostenstelle vorhanden?
Betrag gültig?
Begründung vorhanden?
Genehmiger ermittelbar?
benötigte Dokumente verknüpft?

Fehlt etwas, setzt den Status auf Rückfrage und informiert den Antragsteller. Startet keine Genehmigung mit halben Daten.

3.3 Genehmiger ermitteln

Die Freigabelogik kann aus einer separaten Konfigurationsliste kommen, zum Beispiel:

Kostenstelle	Kategorie	Genehmigerrolle	Vertretung
IT	Software	IT-Leitung	Stellvertretung IT
Operations	Dienstleistung	Operations-Leitung	Geschäftsführung

Das ist wartbarer als hart codierte E-Mail-Adressen in mehreren Flow-Aktionen.

3.4 Status vor der Genehmigung schreiben

Setzt den Vorgang auf In Prüfung, speichert den Genehmiger und schreibt eine technische Korrelation. Erst danach startet ihr die Genehmigung.

Warum diese Reihenfolge? Weil ein Nutzer sonst eine Benachrichtigung bekommen kann, während die SharePoint-Liste noch „Eingereicht“ zeigt.

3.5 Genehmigung starten und warten

Power Automate stellt dafür die Aktion Start and wait for an approval bereit. Genehmiger können je nach Client unter anderem per E-Mail oder im Approval Center reagieren.[5]

Die Anfrage sollte mindestens enthalten:

Vorgangsnummer und Titel
Antragsteller
Kostenstelle und Kategorie
Betrag
Begründung
Link zum SharePoint-Vorgang
Link zu relevanten Dokumenten
klare Entscheidungsfrage

3.6 Entscheidung zurückschreiben

Nach der Antwort schreibt der Flow zurück:

finalen Status
Entscheider
Zeitpunkt
Kommentar
technische Run- oder Korrelations-ID

Die Benachrichtigung an den Antragsteller kommt nach dem erfolgreichen Update. So verweist die Mail immer auf einen Vorgang, dessen Status bereits stimmt.

3.7 Fehlerpfad einbauen

Ein produktiver Flow braucht einen kontrollierten Fehlerpfad:

Hauptlogik in einem Scope
Fehler-Scope mit „run after“ für fehlgeschlagene oder abgebrochene Aktionen.[10]
Status auf „Fehler“ setzen
Process Owner informieren
Flow-Run-Link oder Korrelation speichern

„Der Flow ist rot“ ist keine Betriebsstrategie.

Schritt 4: Sonderfälle vor dem Go-live testen

Der Happy Path ist der leichteste Teil. Testet mindestens diese Fälle:

Testfall	Erwartetes Ergebnis
vollständiger Antrag, Genehmigung	Status und Kommentar korrekt gespeichert
vollständiger Antrag, Ablehnung	Ablehnungsgrund sichtbar, Antragsteller informiert
Pflichtfeld fehlt	keine Genehmigung, Status „Rückfrage“
Genehmiger fehlt	Status „Fehler“, Process Owner informiert
Antrag wird doppelt gespeichert	keine doppelte Genehmigung
Genehmiger antwortet verspätet	definierter Reminder-/Eskalationsweg
Flow-Aktion schlägt fehl	Fehlerpfad greift, Vorgang bleibt auffindbar
nicht berechtigter Nutzer öffnet Vorgang	Zugriff wird wie vorgesehen verweigert

Wenn eine Genehmigung voraussichtlich lange laufen kann, reicht ein einzelner wartender Flow laut Microsoft-Dokumentation nicht als robuste Architektur. Microsoft beschreibt für langlaufende Freigaben ein Zwei-Flow-Muster mit Dataverse.[5] Prüft in solchen Fällen Laufzeitgrenzen, Lizenzierung, Datenmodell und Betriebsanforderungen separat.

Schritt 5: Governance nicht nachträglich ankleben

Power Automate kann Geschäftsdaten über viele Connectoren bewegen. DLP-Policies helfen Administratoren festzulegen, welche Connectoren und Aktionen Daten austauschen dürfen.[6] Das ersetzt kein vollständiges Security- und Berechtigungskonzept, ist aber ein wichtiges Geländer.

Für den Betrieb solltet ihr mindestens festlegen:

In welcher Umgebung wird entwickelt und betrieben?
Wer ist Process Owner?
Wer ist technischer Co-Owner?
Welche Verbindungskonten werden verwendet?
Wie werden Änderungen getestet und ausgerollt?
Was passiert, wenn ein Owner das Unternehmen verlässt?
Wie werden Fehler, Laufzeiten und offene Vorgänge überwacht?
Wann wird der Prozess fachlich überprüft?

Microsoft empfiehlt mit wachsender Power-Platform-Nutzung eine bewusste Environment-Strategie und einen nachvollziehbaren ALM-Weg statt ungeordneter Produktion im Default Environment.[7]

Für einen kleinen Team-Flow muss daraus kein Enterprise-Programm werden. Aber geschäftskritische Automatisierung gehört nicht an ein einziges persönliches Konto.

Schritt 6: Copilot erst auf den fertigen Prozess setzen

Jetzt wird es interessant.

Wenn Vorgänge, Dokumente, Status und Verantwortlichkeiten strukturiert vorliegen, kann Copilot beim Finden, Zusammenfassen und Einordnen helfen. Er ersetzt aber nicht eure Freigaberegel.

Ein SharePoint Agent kann auf definierte Sites, Bibliotheken, Ordner oder Dateien begrenzt und mit einem Zweck sowie Verhalten versehen werden.[1][2]

Seine Antworten hängen weiterhin von den Rechten des jeweiligen Nutzers auf die eingebundenen Quellen ab.[1][2][3]

Daraus ergeben sich sinnvolle Fragen wie:

Welche genehmigten Beschaffungen zum Thema Endpoint Security liegen vor?
Welche Richtlinien gelten für Softwarebeschaffung?
Welche Dokumente muss ein Antrag enthalten?
Wo unterscheiden sich aktuelle Richtlinie und alte Arbeitsanweisung?

Aber Vorsicht bei Listendaten: Microsofts aktuelle Supportseiten zeigen zwar das Erstellen eines Agents aus einer Liste als Oberfläche, die FAQ sagt zugleich, dass Agents derzeit keine Daten aus Lists verwenden.[1][2] Genau solche Details müsst ihr im eigenen Tenant testen, bevor ihr einen Prozess darauf aufbaut.

Die richtige Reihenfolge bleibt:

Prozess klären
Daten strukturieren
Rechte prüfen
Automatisierung testen
KI als zusätzliche Nutzungsschicht pilotieren

Schritt 7: Aus einem Flow einen betriebenen Prozess machen

Ein Go-live ist kein Endpunkt.

Prüft monatlich:

Wie viele Vorgänge hängen in „Rückfrage“?
Welche Genehmigungen überschreiten die vereinbarte Frist?
Wie oft läuft der Fehlerpfad?
Gibt es verwaiste Verbindungen oder Owner?
Stimmen Rollen und Freigabematrix noch?
Sind alte Dokumente weiterhin als gültige Quelle sichtbar?
Sind SharePoint-Sites, Freigaben und Berechtigungen noch sauber?

Wenn ihr echte Eventdaten über längere Zeit sammelt, kann Process Mining helfen, reale Varianten und Engpässe sichtbar zu machen.[8] Eine konkrete Zeitersparnis dürft ihr aber erst behaupten, wenn ihr Vorher und Nachher tatsächlich gemessen habt.

Was ihr am Ende wirklich gewinnt

Nicht „einen Flow“.

Ihr gewinnt:

einen gemeinsamen Status statt Postfachwissen,
klare Verantwortung statt Weiterleitungs-Pingpong,
nachvollziehbare Entscheidungen statt mündlicher Erinnerung,
strukturierte Daten für Auswertung und Verbesserung,
eine belastbare Grundlage für Copilot und Agents.

Das ist der Unterschied zwischen einer Automatisierung, die in einer Demo funktioniert, und einem Prozess, der im Alltag trägt.

Kompakte Go-live-Checkliste

Zulässige und nicht zulässige Claims

Zulässige Aussagen

„SharePoint kann den nachvollziehbaren Vorgangsstatus und die zugehörigen Dokumentreferenzen halten; Power Automate kann darauf einen Freigabeablauf aufbauen.“[4][5]
„Trigger Conditions und klar getrennte Fehler-Scopes reduzieren unnötige Starts und machen Fehlerpfade kontrollierbarer.“[9][10]
„DLP-Policies steuern zulässige Datenflüsse zwischen Connectoren; sie ersetzen kein vollständiges Berechtigungs-, Betriebs- oder Compliance-Modell.“[6]
„Process Mining kann auf Basis geeigneter Eventdaten Prozessvarianten und Engpässe sichtbar machen.“[8]

Nicht zulässige oder zu starke Aussagen

„Der Flow ist die revisionssichere Wahrheit.“ Der Artikel beschreibt ein Betriebs- und Datenmodell, keinen pauschalen Rechts- oder Compliance-Nachweis.
„Die Automatisierung spart garantiert Zeit.“ Eine konkrete Wirkung darf erst nach einer dokumentierten Vorher-/Nachher-Messung behauptet werden.
„DLP macht den Prozess automatisch sicher oder compliant.“ DLP ist eine Teilkontrolle; Identitäten, Berechtigungen, Datenmodell, Freigaben und Betrieb bleiben getrennte Aufgaben.
„Copilot oder ein Agent kann den Prozess ohne menschliche Prüfung übernehmen.“ Für Entscheidungen, Ausnahmen und KI-Ausgaben bleiben definierte Freigaben und Kontrollen erforderlich.[2]

Der nächste sinnvolle Schritt

Wenn eure Freigaben heute über E-Mail, Excel und Zuruf laufen, startet nicht mit einem riesigen Transformationsprojekt. Nehmt einen Vorgang mit klarer Entscheidung und baut ihn sauber Ende-zu-Ende.

WITC unterstützt euch beim Datenmodell, beim Power-Automate-Flow, bei Governance und beim stabilen Betrieb. Wenn ihr herausfinden wollt, welcher Prozess sich als erster eignet, nutzt unsere Kontaktseite.

Weiterführende WITC-Artikel

Sources

Microsoft 365

SharePoint & Entwicklung

KI & Copilot

Tools

SharePoint Module

Walther IT Consulting