Urlaubsstatus in SharePoint mit Power Automate prüfen und Freigaben sauber steuern

Wie prüft man in Power Automate, ob eine Person während eines bestimmten Zeitraums bereits Urlaub oder eine Abwesenheit eingetragen hat, und wie lässt sich diese Prüfung mit einem Genehmigungsworkflow verbinden? Die Antwort hängt vor allem vom Datenmodell der Abwesenheitsliste ab. Wenn Datumsfelder korrekt gesetzt sind und der Abwesenheitsstatus in einem klaren Statusfeld gespeichert wird, lässt sich die Prüfung mit einer einfachen OData-Filterabfrage lösen. Sobald Zeitzone, Überschneidungserkennung und Vertretungsregeln hinzukommen, wird das Modell schnell komplexer.

Dieser Ratgeber beschreibt, wie ein Urlaubsstatus SharePoint Power Automate Prozess aufgebaut wird: von der Liste über die Prüflogik bis zur Freigabe und Benachrichtigung. Für die allgemeine Prozessarchitektur ist Power Automate SharePoint Prozesse der passende Grundlagenartikel.

Das Datenmodell für Urlaub, Abwesenheit und Freigabestatus

Das Datenmodell ist die Grundlage für alle nachgelagerten Automatisierungen. Unklare oder inkonsistente Felder in der Abwesenheitsliste machen jede Prüflogik fragil.

Empfohlene Spaltenstruktur für eine Abwesenheitsliste

Warum Datum und Uhrzeit statt nur Datum wichtig ist

Das Speichern von Datum und Uhrzeit statt nur des Datums ist für eine korrekte Überschneidungsprüfung wichtig. Wenn nur das Datum gespeichert wird, rechnet SharePoint intern mit Mitternacht UTC, was zu falschen Vergleichen führen kann, sobald Zeitzonenunterschiede zwischen Tenant und Nutzerstandort bestehen.

Für einen Abwesenheitszeitraum, der ganztägig gilt, empfiehlt es sich, das „Von“-Datum auf 00:00:00 UTC und das „Bis“-Datum auf 23:59:59 UTC zu setzen, angepasst an die Tenant-Zeitzone. Alternativ kann die Zeitzonenumrechnung im Flow mit convertTimeZone() vorgenommen werden.

Statusmodell klar definieren

Der Status eines Abwesenheitsantrags sollte immer den aktuellen Genehmigungsstand widerspiegeln. Ein Antrag, der weder genehmigt noch abgelehnt wurde, darf für andere Prüflogiken nicht als „gültige Abwesenheit“ gelten. Deshalb sollte die Prüfung auf Überschneidungen immer nur auf Einträge mit dem Status „Genehmigt“ reagieren.

Vor einer Aktion prüfen, ob eine Person bereits abwesend ist

Die häufigste Anforderung lautet: Bevor ein Auftrag zugewiesen, eine Aufgabe erstellt oder eine Ressource gebucht wird, soll geprüft werden, ob die betreffende Person in dem relevanten Zeitraum abwesend ist. Wenn daraus Aufgaben in SharePoint entstehen, hilft das Status- und Trigger-Modell aus SharePoint-Aufgaben mit Power Automate verbinden.

Abfrage mit OData-Filter

Die Aktion „Get items“ in Power Automate ermöglicht eine gefilterte Abfrage der SharePoint-Liste. Für eine Überschneidungsprüfung mit einem definierten Zeitraum lautet der OData-Filter:

Person/EMail eq 'user@domain.com' and Status eq 'Genehmigt' and Von le '2024-07-15T23:59:59Z' and Bis ge '2024-07-10T00:00:00Z'

Dieser Filter gibt alle genehmigten Abwesenheitseinträge für die genannte Person zurück, die sich mit dem Zeitraum 10.07.–15.07.2024 überschneiden. Die Logik dahinter: Ein Eintrag überschneidet sich mit dem gesuchten Zeitraum, wenn sein Ende nach oder gleich dem Anfang des gesuchten Zeitraums liegt UND sein Anfang vor oder gleich dem Ende des gesuchten Zeitraums liegt.

Ergebnis auswerten

Nach der Abfrage prüft eine Bedingung im Flow, ob die Ergebnismenge leer ist:

length(body('Get_items')?['value']) is greater than 0

Wenn wahr: Die Person ist im Zeitraum abwesend. Der Flow kann daraufhin:

• Die Zuweisung ablehnen und den Anfragenden benachrichtigen,
• einen alternativen Verantwortlichen vorschlagen,
• die Aufgabe mit einem Hinweis auf die Abwesenheit erstellen und die Vertretungsperson in Kopie setzen.

Wenn falsch: Die Person ist verfügbar. Der Flow fährt mit der ursprünglichen Aktion fort.

Vertretungsperson aus dem Abwesenheitseintrag nutzen

Wenn die Abwesenheitsliste eine Spalte „Vertretung“ enthält und diese befüllt ist, kann der Flow die Vertretungsperson aus dem Abwesenheitseintrag auslesen und für die Zuweisung verwenden. Das vermeidet eine manuelle Suche nach der Vertretung und macht den Prozess selbsttragend.

Genehmigungsworkflow und Statuswechsel sauber aufbauen

Ein Urlaubsantrag in SharePoint löst einen Genehmigungsworkflow aus, wenn ein neuer Eintrag mit dem Status „Beantragt“ erstellt wird. Power Automate bietet dafür die Aktion „Genehmigung starten und warten“ aus dem Approval-Connector.

Ablauf eines einfachen Genehmigungsworkflows

1. Trigger: Neuer Eintrag in der Abwesenheitsliste mit Status „Beantragt“.
2. Prüfung auf Überschneidung: Flow prüft, ob bereits ein genehmigter Eintrag für diese Person im Zeitraum existiert.
3. Wenn Konflikt: Flow setzt Status auf „Abgelehnt“, Kommentar wird automatisch gesetzt, Person wird benachrichtigt.
4. Wenn kein Konflikt: Genehmigungsanfrage wird an den Vorgesetzten gesendet.
5. Genehmigt: Status wird auf „Genehmigt“ gesetzt, Genehmigungsdatum und Genehmiger werden eingetragen, Person und optional Vertretung werden benachrichtigt.
6. Abgelehnt: Status wird auf „Abgelehnt“ gesetzt, Ablehnungskommentar wird eingetragen, Person wird benachrichtigt.

Wer genehmigt: Vorgesetzte oder Teamleitung

Der Genehmiger muss aus einer zuverlässigen Quelle stammen. Drei Ansätze sind verbreitet:

• Festes Feld „Genehmiger“ in der Liste: Die antragstellende Person trägt beim Anlegen ihren Vorgesetzten ein. Einfach, aber fehleranfällig, wenn das Feld leer gelassen oder falsch befüllt wird.
• Lookup aus der Personalliste: Eine zentrale Personalliste in SharePoint enthält für jede Person die zugeordnete Führungskraft. Der Flow liest den Genehmiger automatisch aus dieser Liste.
• Azure AD / Entra ID Manager-Attribut: Der Flow verwendet die Aktion „Office 365-Benutzer abrufen“ und liest das Manager-Attribut aus Entra ID. Dieses Attribut muss in Entra ID gepflegt sein und stimmt in kleineren Unternehmen nicht immer mit der tatsächlichen Genehmigungsstruktur überein.

Die Kombination aus Personalliste und einem Fallback auf ein manuelles Genehmiger-Feld ist für die meisten Unternehmensgrößen ein guter Kompromiss.

Timeout und manuelle Eskalation

Approval-Flows können mit einem Timeout versehen werden. Wenn nach einer definierten Zeit keine Entscheidung getroffen wurde, eskaliert der Flow automatisch:

• Erinnerungs-E-Mail an den Genehmiger,
• nach weiterer Wartezeit Benachrichtigung des nächsthöheren Vorgesetzten oder des HR-Teams.

Konflikte, Vertretung und Benachrichtigungen behandeln

Überschneidungskonflikt zwischen mehreren Anträgen

Wenn mehrere Personen eines Teams gleichzeitig Urlaub beantragen und die Abdeckung des Teams ein Thema ist, reicht eine einfache Prüfung auf Einzelpersonenebene nicht aus. Es braucht dann eine Team-Abdeckungsprüfung.

Ein Ansatz dafür: In einer separaten Teamliste ist pro Team definiert, wie viele Personen gleichzeitig abwesend sein dürfen. Beim Eingang eines neuen Antrags prüft der Flow, wie viele genehmigte Abwesenheiten für dasselbe Team im gesuchten Zeitraum bereits vorhanden sind. Liegt die Anzahl über dem definierten Maximum, kann der Antrag nicht automatisch genehmigt werden und wird zur manuellen Prüfung markiert.

Vertretungsbenachrichtigung

Wenn eine Abwesenheit genehmigt wurde, sollte die eingetragene Vertretungsperson automatisch informiert werden. Die Benachrichtigung sollte enthalten:

• Name der abwesenden Person,
• Zeitraum der Abwesenheit,
• Art der Abwesenheit (Urlaub, Dienstreise etc.),
• optionale Hinweise auf offene Aufgaben oder laufende Prozesse.

Eine Teams-Nachricht oder eine strukturierte E-Mail sind für diese Benachrichtigung geeignet. Eine strukturierte Teams-Adaptive-Card mit den wichtigsten Informationen ist für die Vertretungsperson übersichtlicher als ein Freitext-E-Mail.

Stornierung und Rücknahme

Ein genehmigter Urlaub kann storniert werden. Dafür wird der Status auf „Storniert“ gesetzt. Der Flow erkennt diese Statusänderung und informiert Genehmiger und Vertretung. Wichtig: Der Status „Storniert“ darf nicht mit „Abgelehnt“ gleichgestellt werden. Ein stornierter Antrag war genehmigt und wurde bewusst zurückgezogen. Ein abgelehnter Antrag war nie genehmigt.

Typische Fehler bei Datumsfeldern, Zeitzonen und Mehrfacheinträgen

Zeitzonen-Bugs bei Datumsvergleichen

Der häufigste Fehler bei Abwesenheitsprüfungen ist ein Zeitzonenproblem. SharePoint speichert Datumsfelder intern in UTC. Power Automate verarbeitet Datumsausdrücke ebenfalls standardmäßig in UTC. Wenn Benutzer ein Datum in ihrer lokalen Zeitzone eingeben (z.B. mitteleuropäische Sommerzeit, UTC+2), kann es zu einer Verschiebung um zwei Stunden kommen.

Konkrete Auswirkung: Ein Antrag mit „Von: 15.07.2024 00:00 Uhr MEZ“ wird in SharePoint als „14.07.2024 22:00 UTC“ gespeichert. Ein Filter, der auf den 15.07. prüft, findet den Eintrag möglicherweise nicht.

Lösung: Entweder alle Datumsvergleiche konsequent in UTC durchführen und sicherstellen, dass das Formular Datumswerte in UTC übergibt, oder die Funktion convertTimeZone() in Power Automate verwenden, um alle Werte vor dem Vergleich in eine einheitliche Zeitzone zu überführen.

Mehrfache Einträge für denselben Zeitraum

Wenn ein Benutzer mehrere Anträge für überlappende Zeiträume einreicht, entstehen mehrfache Einträge. Die Prüfung bei der Antragserfassung – nicht erst bei der Genehmigung – verhindert, dass solche Überlappungen in den Workflow eintreten.

Beim Anlegen eines neuen Antrags prüft der Flow:

• Hat diese Person bereits einen Antrag mit Status „Beantragt“ oder „Genehmigt“ für diesen Zeitraum?
• Wenn ja: Neuen Antrag ablehnen und Benutzer informieren.

Personenfeld-Fehler bei Abfragen

Der OData-Filter auf eine Personenspalte erfordert die E-Mail-Adresse im UPN-Format, nicht den Anzeigenamen. Wenn der Flow die Person aus einem Formulareingang oder aus einer vorherigen Aktion bezieht, muss sichergestellt sein, dass das Format der E-Mail-Adresse korrekt ist.

Typischer Fehler: Der Filter verwendet Person/Title eq 'Max Mustermann' statt Person/EMail eq 'max.mustermann@domain.com'. Das erste Format funktioniert in der Praxis unzuverlässig, weil Anzeigenamen nicht eindeutig sind.

So bleibt die Abwesenheitsprüfung auch im Tagesgeschäft verlässlich

Ein stabiler Abwesenheits- und Urlaubsprozess in SharePoint und Power Automate setzt vor allem zwei Dinge voraus: ein sauberes Datenmodell mit klaren Statuswerten und eine Filterlogik, die Zeitzonen und Überschneidungen korrekt behandelt. Beides lässt sich in der Entwicklungsphase mit einer Handvoll Testfällen gezielt prüfen.

Für Datenschutz und Berechtigungen gilt: Abwesenheitslisten enthalten personenbezogene Daten. Der Zugriff sollte auf Personen beschränkt sein, die diese Daten für ihre Rolle benötigen. Genehmigende sehen üblicherweise alle Anträge ihres Teams, nicht die anderer Teams. Mitarbeitende sehen typischerweise nur ihre eigenen Einträge. Die Berechtigungsstruktur der Liste und eine mögliche Zeilenebenen-Absicherung über Power Apps oder spezifische Ansichten sollten frühzeitig definiert werden.

Wenn Abwesenheiten in einem größeren Zusammenhang stehen, zum Beispiel als Teil eines vollständigen Personalverwaltungsprozesses mit Power Apps, beschreibt der Artikel Anwesenheit & Urlaub digital verwalten mit Power Apps das übergeordnete Prozessmodell.