Zeitgesteuerte Flows in Power Automate entwerfen — Monatsabschlussverarbeitung, Geschäftstagsprüfung und Erinnerungen in der Praxis

„Wenn sich das Monatsende nähert, verschickt jemand aus der Buchhaltung an alle Abteilungen eine E-Mail: ‚die Frist für die Spesenabrechnung ist der ◯.‘“ „Jeden Morgen nach Arbeitsbeginn öffnet jemand die Bestellliste und prüft mit bloßem Auge, ob noch etwas unbearbeitet ist.“ „Dokumente, deren Einreichungsfrist verstrichen ist, werden mit einem Verzeichnis abgeglichen und einzeln nachverfolgt.“ Selbst in Unternehmen, die bereits Microsoft 365 eingeführt haben, bleibt Arbeit, bei der „eine Person anhand der Beobachtung eines Kalenders und eines Verzeichnisses handelt“, überraschend verbreitet. Vergessen wird zum Vorfall, und doch besteht der einzige Mechanismus, der das Vergessen verhindert, aus dem Gedächtnis dieser Person und ihrem Outlook-Kalender.

Die zeitgesteuerte Ausführung von Power Automate (der Recurrence-Trigger) kann diese Art wiederkehrender Aufgaben automatisieren. Doch in dem Moment, in dem man versucht, dies für die japanische Geschäftspraxis tatsächlich aufzubauen, stößt man sofort auf drei Mauern: Der Standardzeitpunkt ist UTC (koordinierte Weltzeit), das Konzept eines „Geschäftstags“ existiert nicht als integrierte Funktion, und man muss Ausdrücke selbst schreiben, um Dinge wie „Monatsende“ oder den „20. als Abschlusstermin“ zu bestimmen. Dieser Artikel legt die Spezifikationen und Fallstricke des Recurrence-Triggers, einen Werkzeugkasten für Datumsberechnungen, die Geschäftstagsprüfung anhand einer Feiertags-Mastertabelle, ein Erinnerungsdesign, das nicht zu sehr nervt, und die betrieblichen Risiken speziell zeitgesteuerter Flows dar.

Übrigens haben wir ausführlich beschrieben, wie sich die japanischen Datumsanforderungen der Kaiserzeit-Ären, Feiertage und Abschlusstermine systemübergreifend behandeln lassen, in einem separaten Artikel: Japanische Ären-Daten, Feiertage und Abschlusstermin-Verarbeitung in Geschäftsanwendungen — ärenresistentes Design, JapaneseCalendar und Geschäftstagsberechnungen in der Praxis. Dieser Artikel ist das praktische Begleitstück, das diese Überlegungen auf Power-Automate-Flows anwendet.

1. Das Fazit zuerst

• Die Zeit des Recurrence-Triggers wird als UTC behandelt, sofern Sie keine Zeitzone angeben. Sie verhindern den Unfall, „jeden Morgen um 9“ gedacht zu haben, es aber tatsächlich um 18 Uhr japanischer Zeit laufen zu lassen, indem Sie im Zeitzonenfeld „(UTC+09:00) Osaka, Sapporo, Tokio“ wählen und die Startzeit ausdrücklich festlegen.¹²
• „Nur an Werktagen ausführen“ lässt sich mit Häufigkeit „Woche“ plus Wochentagsauswahl (Mo–Fr) bauen. Feiertage werden dabei jedoch nicht berücksichtigt. Ein festes Datum wie „jeden 20. des Monats“ lässt sich mit Start-Datum/-Zeit plus Häufigkeit „Monat“ bauen, aber Sie können kein bewegliches Datum wie „der letzte Tag jeden Monats“ oder „der vorherige Geschäftstag, falls der Abschlusstermin ein Feiertag ist“ angeben, sodass „jeden Tag ausführen und mit einem Ausdruck prüfen“ die praktische Lösung ist.²
• utcNow() innerhalb eines Ausdrucks ist ebenfalls immer UTC. Wandeln Sie es mit convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time') um, bevor Sie „heute“ in japanischer Zeit verwenden. Vergessen Sie die Umwandlung in einem Flow, der zur 8-Uhr-Stunde läuft, wird aus „heute“ der Vortag.³⁴
• Es gibt keinen integrierten Mechanismus zur Erkennung japanischer Feiertage. Auch in der Liste der Ausdrucksfunktionen gibt es keine Feiertagsfunktion,⁵ sodass es Standardpraxis ist, eine eigene Feiertags-Mastertabelle zu führen (eine SharePoint-Liste o. Ä.), den Flow gleich am Anfang bestimmen zu lassen, ob „heute ein Geschäftstag ist“, und ihn zu beenden, wenn nicht. Die Feiertags-CSV des Kabinettsbüros kann als Primärquelle der Mastertabelle dienen.⁶
• Bauen Sie Erinnerungen als eine Nachricht pro Person, gebündelt, statt einer Nachricht pro Datensatz. Mit Datenoperationsaktionen wie Filter array und Create HTML table lässt sich das lesbar aufbauen, während man verschachtelte Apply-to-each-Schleifen vermeidet.⁷
• Bei einem zeitgesteuerten Flow ist schwer zu bemerken, dass er „nicht läuft“. Entwerfen Sie Fehlerbenachrichtigungen und einen Ausführungsnachweis von Anfang an, unter der Annahme folgender Spezifikationen: Abschaltung nach 14 aufeinanderfolgenden Fehlschlägen, Abschaltung nach 90 Tagen ohne Trigger, und ein Ausführungsverlauf, der standardmäßig nur 28 Tage abdeckt.⁸⁹

2. Bestandsaufnahme der „Arbeit, bei der eine Person einen Kalender beobachtet und handelt“

Das Erste, was zu tun ist, ist nicht der Bau eines Flows — es ist, jedes einzelne Stück „durch Kalenderbeobachtung getriebene Arbeit“ zu identifizieren und zu sortieren, ob sie sich jeweils für die zeitgesteuerte Ausführung eignet.

Für die Sortierung gibt es drei Kriterien: Lässt sich die Bedingung als Daten ausdrücken (ein „irgendwie verdächtig wirkender Fall“ lässt sich nicht automatisieren), lässt sich die Regel für den Ausführungstag in Worte fassen, und lässt es sich am nächsten Tag wiederherstellen, selbst wenn es fehlschlägt (was das nicht kann, ist Entwicklungsterrain aus Kapitel 8).

Von diesen ist der zweite Punkt die schwierigste Stelle in der japanischen Geschäftspraxis. Selbst etwas so Einfaches wie „die Abschlusserinnerung zum Monatsende senden“ beinhaltet tatsächlich, dass eine Person Anpassungen vornimmt wie „auf den vorherigen Geschäftstag vorziehen, falls das Monatsende auf ein Wochenende oder einen Feiertag fällt, und in einem Golden-Week-Jahr vor der Ferienzeit senden“. Betrachten Sie das Ausformulieren dieses stillschweigenden Wissens als explizite Spezifikation als den eigentlichen Kern des Flow-Baus. Bauen Sie den Flow, während dies unklar bleibt, verlieren Sie Vertrauen in einer Weise wie „eine Mahn-E-Mail ging an einem Feiertag hinaus“ oder „die Erinnerung vor den Ferien ging während der Ferien selbst hinaus“.

3. Die Grundlagen und Fallstricke des Recurrence-Triggers

Ein zeitgesteuerter Cloud-Flow wird als „geplanter Cloud-Flow“ erstellt, und Sie legen Häufigkeit und Intervall mit dem Recurrence-Trigger fest.¹ Die Häufigkeit lässt sich aus Sekunden, Minuten, Stunden, Tagen, Wochen oder Monaten wählen, mit einem Mindestintervall von 60 Sekunden und einem Höchstwert von 500 Tagen.⁸ Die Spezifikation selbst ist einfach, doch es ist auch ein Trigger mit reichlich Fallstricken.

Fallstrick 1: Standard ist UTC — „sollte 9 Uhr sein, lief aber um 18 Uhr“

Das ist der häufigste Unfall. Wählen Sie keine Zeitzone aus, wird die Startzeit des Recurrence-Triggers im UTC-Format mit angehängtem Z interpretiert (YYYY-MM-DDThh:mm:ssZ). Wählen Sie im Zeitzonenfeld Japan aus, wird die Startzeit als Ortszeit dieser Zeitzone behandelt (YYYY-MM-DDThh:mm:ss, ohne Z).¹² Bauen Sie einen „Flow, der jeden Morgen um 9 Uhr benachrichtigt“, lautet der korrekte Ansatz, die Zeitzone auf „(UTC+09:00) Osaka, Sapporo, Tokio“ und die Startzeit auf 9:00 zu setzen.

Fallstrick 2: Lassen Sie die Startzeit weg, feuert er einmal im Moment des Speicherns

Geben Sie kein Start-Datum/-Zeit an, feuert die erste Ausführung sofort im Moment, in dem Sie den Flow speichern.² Beim Testen ist das unproblematisch, doch es kann zu einem Unfall werden, bei dem Sie einen Flow mit einer Mahn-E-Mail abends speichern und dabei alle sofort gemahnt werden. Geben Sie das Start-Datum/die Startzeit immer an.

Geben Sie außerdem in den erweiterten Optionen nicht „zu diesen Stunden/zu diesen Minuten“ an, wird jede Ausführung nach der ersten relativ zur Zeit der vorherigen Ausführung berechnet, sodass sich aufgestaute Verzögerung dazu führt, dass die Ausführungszeit nach und nach abdriftet.² Für einen Flow, der Sie jeden Tag zu einer festen Zeit laufen lassen wollen, ist es am sichersten, zusätzlich zum Start-Datum/-Zeit auch die Ausführungszeit ausdrücklich anzugeben.

Fallstrick 3: „Nur Werktage“ funktioniert, doch die monatlichen Detaileinstellungen sind begrenzt

Stellt man die Häufigkeit auf „Woche“, kann man Wochentage wählen (Mo–Fr), und bei „Tag“ oder „Woche“ lässt sich zusätzlich eine Tageszeit (Stunde/Minute) angeben. Mit anderen Worten: „9 Uhr nur an Werktagen“ lässt sich allein mit den Triggereinstellungen bauen. Andererseits sind diese Detailoptionen nur verfügbar, wenn die Häufigkeit „Tag“ oder „Woche“ ist — die Häufigkeit „Monat“ besitzt kein Feld zur Angabe eines Datums wie „jeden 20. des Monats“ oder „der letzte Tag jeden Monats“.²

Allerdings: Ist das Datum fest und monatlich, müssen Sie ihn nicht jeden Tag laufen lassen. Setzen Sie das Start-Datum/-Zeit auf das Zieldatum (z. B. 9:00 am 20. des nächsten Monats) und die Häufigkeit auf „Monat“, wird die Ausführung monatlich, ausgehend vom Start-Datum/-Zeit, sodass sich „9 Uhr am 20. jeden Monats“ allein mit den Triggereinstellungen bauen lässt.² Vermeiden Sie es, einen Flow, der nur 12-mal im Monat laufen muss, 365-mal am Tag zu starten und die meisten davon per Bedingungsprüfung zu verwerfen — das macht den Ausführungsverlauf schwerer lesbar und verschwendet unnötig Anfragekontingent.

Die Konfiguration „jeden Tag ausführen und am Anfang des Flows mit einem Ausdruck prüfen, ob heute das Zieldatum ist“ wird notwendig für monatliche Arbeit, bei der sich das Datum selbst verschiebt. Daten wie „der letzte Tag jeden Monats“ (der 28. bis 31., je nach Monat), „der vorherige Geschäftstag, falls der 20. ein Wochenende oder Feiertag ist“, oder „der N-te Geschäftstag jeden Monats“ lassen sich vom Trigger nicht ausdrücken. Diesen Beurteilungsausdruck behandeln wir im nächsten Kapitel. Beachten Sie außerdem, dass die Angabe eines festen Datums vom 29. bis 31. als Starttag erfordert, durch tatsächliche Implementierung zu testen, was in einem Monat passiert, in dem dieser Tag nicht existiert, sodass es sicherer ist, bei allem rund um das Monatsende von Anfang an zu „jeden Tag ausführen + prüfen“ zu tendieren.

Fallstrick 4: Sommerzeit — nur bei ausländischen Standorten relevant

Schreiben Sie die Zeit in UTC, ohne eine Zeitzone auszuwählen, verschiebt sich die Ausführungszeit um eine Stunde, jedes Mal, wenn eine Region mit Sommerzeit (DST) ihre saisonale Umstellung vornimmt. Haben Sie eine Zeitzone ausgewählt, hält der Zeitplan mit der saisonalen Umstellung Schritt und bleibt konsistent.¹⁰ Japan kennt keine Sommerzeit, sodass bei rein inländischer Nutzung kein realer Schaden entsteht, doch wenn derselbe Flow auch Benachrichtigungen für einen ausländischen Standort behandelt, müssen Sie die Zeitzone dieses Standorts ausdrücklich auswählen.

Fallstrick 5: Ein in den Trigger geschriebener Ausdruck wird beim Speichern fixiert

Schreiben Sie einen Ausdruck wie utcNow() in die Eingabe eines Triggers, wird dieser Wert im Moment des Speicherns des Flows berechnet und fixiert. Er wird nicht bei jeder Ausführung neu berechnet.¹¹ Behalten Sie im Kopf, dass die Idee, einen Ausdruck in den Trigger zu setzen, weil „die Startzeit heute sein soll“, schlicht nicht funktioniert.

Fallstrick 6: Die Zeit, in der er abgeschaltet war, wird nicht nachgeholt

Der Recurrence-Trigger arbeitet nach dem Wiederaufnehmen keine Zeitpläne im Stapel nach, die verstrichen sind, während der Flow abgeschaltet war — er nimmt einfach ab dem nächsten Zyklus wieder auf.¹⁰ Ein Unfall wie „einen Monatsend-Flow für ein paar Tage wegen einer Änderung abschalten, und dabei genau den Monatsend-Ausführungstermin überspannen, sodass die Ausführung dieses Monats einfach nie stattfand“ ist durchaus möglich. Machen Sie es zur Standardpraxis, das nächste geplante Ausführungsdatum zu prüfen, bevor Sie einen zeitgesteuerten Flow abschalten.

4. Ein Werkzeugkasten für Datumsberechnungen — Monatsende, Monatsanfang und Abschlusstermine mit Ausdrücken beurteilen

Datumsberechnungen innerhalb eines Flows werden mit denselben Ausdrücken (Funktionen) geschrieben, die auch bei Logic Apps gelten.⁵ Als Voraussetzung gilt: Was utcNow() zurückgibt, ist immer die aktuelle Zeit in UTC.¹² Strukturiert man die Dinge daher so, dass man einmal am Anfang des Flows „heute in japanischer Zeit“ aufbaut, in einer Variablen (oder einem Compose) ablegt und ab dann wiederverwendet, werden die Ausdrücke deutlich lesbarer.

convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd')

convertTimeZone(Zeitstempel, Quelle, Ziel, Format) ist die Funktion zur Zeitzonenumwandlung,¹³ und der Zeitzonenname verwendet den Namen aus Windows’ Liste der Zeitzonen. Japans Name lautet „Tokyo Standard Time“.⁴ Möchten Sie lieber keinen Ausdruck schreiben, gibt es auch eine Aktion „Zeitzone konvertieren“, die dasselbe tut.

Der Grund, warum die Umwandlung zwingend ist, liegt in der 9-Stunden-Differenz zwischen UTC und japanischer Zeit. Bis 9 Uhr japanischer Zeit ist es in UTC noch der Vortag. Schreiben Sie formatDateTime(utcNow(), 'yyyy-MM-dd') in einem Flow, der um 8 Uhr läuft, ist das zurückgegebene „heute“ das Datum von gestern. Da diese Datumsabweichung je nach Ausführungszeit auftritt oder nicht, ist sie beim Testen leicht zu übersehen, und sie kommt in der Produktion in Formen zutage wie „eine Verarbeitung, die eigentlich Monatsanfang sein sollte, lief auch am allerletzten Tag des Monats“.

Hier eine Zusammenfassung der Beurteilungsmuster, nachdem Sie „heute in japanischer Zeit“ aufgebaut haben (im Folgenden Heute genannt).

addDays, addToTime, startOfMonth, formatDateTime und dayOfWeek sind allesamt Funktionen, die in der gemeinsamen Ausdrucksreferenz von Logic Apps/Power Automate definiert sind.⁵ Die kombinierten Ausdrücke in der obigen Tabelle sind das eigene Implementierungsmuster des Autors; übernehmen Sie sie also, testen Sie mit Daten, die Monatsende, Monatsanfang und ein Schaltjahr (29. Februar) überspannen, bevor Sie sie in Produktion nehmen. Wie erschreckend ein Datumsfehler sein kann, der nur an einem bestimmten Datum auftritt, und wie man die vorab zu testenden Daten auswählt, haben wir in Kapitel 4 des Artikels zu japanischer Ären-Zeitrechnung, Feiertagen und Abschlussterminen beschrieben.

5. Geschäftstagsprüfung — Feiertage in einer Mastertabelle führen

Es gibt keine integrierte Feiertagsprüfung

Zur Wiederholung: Power Automate besitzt keine integrierte Funktion zur Erkennung japanischer Feiertage. Die Wochentagseinstellung des Recurrence-Triggers betrachtet buchstäblich nur den Wochentag, und die Liste der Ausdrucksfunktionen reicht nur bis zu Datumsarithmetik, Formatierung und Zeitzonenumwandlung — es gibt keine Funktion, die „ist dieses Datum ein Feiertag“ zurückgibt. Wir haben in Kapitel 3 des Artikels zu japanischer Ären-Zeitrechnung, Feiertagen und Abschlussterminen ausführlich beschrieben, warum die Berechnung von Feiertagen mit einer Formel grundsätzlich prinzipiell unmöglich ist (die Tagundnachtgleichen werden erst im Vorjahr festgelegt, und Feiertage selbst verschieben sich durch Gesetzesänderungen und Sondermaßnahmengesetze). Das Fazit ist hier dasselbe: Feiertage als Daten (eine Mastertabelle) plus einen Aktualisierungsvorgang zu führen ist die richtige Antwort.

Der einfache Weg, dies in Power Automate zu führen, ist der Aufbau einer „Feiertags-Mastertabelle“ als SharePoint-Liste (eine Datumsspalte plus eine Namensspalte). Als Primärquelle können Sie die vom Kabinettsbüro veröffentlichte CSV der Feiertagsdaten und -namen von 1955 bis zum kommenden Jahr verwenden (Ersatzfeiertage sind ebenfalls als Zeilen enthalten).⁶ Da nur feststehende Daten veröffentlicht werden, muss das Design so weit reichen, dass die Aufgabe, die Daten des kommenden Jahres einmal jährlich in die Mastertabelle zu übernehmen, in den Geschäftskalender aufgenommen wird. Vergessen Sie die Aktualisierung, wird daraus eine tatsächliche Fehlfunktion, in Form einer Mahn-Benachrichtigung, die an einem Feiertag des kommenden Jahres hinausgeht. Führen Sie außerdem betriebliche Schließtage wie Sommerferien oder einen Gründungstag in einer separaten Liste, statt sie in die Feiertags-Mastertabelle zu mischen — denn „eine Fälligkeitsprüfung für Banküberweisungen sollte nur gesetzliche Feiertage betrachten“, während „eine interne Mahn-Erinnerung auch betriebliche Schließtage betrachten sollte“, und die Menge der zu referenzierenden freien Tage unterscheidet sich je nach Zweck.

Eine „Geschäftstags-Schranke“ am Anfang des Flows

Für einen Flow, der nur an Geschäftstagen laufen soll, setzen Sie zusätzlich zur Wochentagseinstellung von Recurrence (Mo–Fr) die folgende Prüfung an den Anfang des Flows.

1. „Heute in japanischer Zeit“ aufbauen (Kapitel 4)
2. SharePoints „Get items“ (Elemente abrufen) gegen die Feiertags-Mastertabelle ausführen und mit einer Filterabfrage wie HolidayDate eq 'Heute' nach dem heutigen Datum suchen¹⁴
3. Dieselbe Suche auch gegen die Liste der betrieblichen Schließtage ausführen
4. Kommt auch nur ein Treffer zurück, die Ausführung mit der Aktion „Terminate“ (Beenden) stoppen

Terminate ist die Aktion, die die Ausführung eines Flows an Ort und Stelle stoppt und in dem von Ihnen angegebenen Zustand beendet (Succeeded/Failed/Cancelled) — sie kann nicht innerhalb einer Apply-to-each- oder Do-until-Schleife platziert werden.¹⁵ Setzen Sie den Zustand hier auf „Cancelled“ (Abgebrochen), lässt sich im Ausführungsverlauf auf einen Blick „ein Tag, der übersprungen wurde, weil er kein Geschäftstag war“ von „ein Tag, an dem die Verarbeitung tatsächlich lief“ unterscheiden. Das macht spätere Untersuchungen deutlich leichter, als alles unter „Succeeded“ zusammenzuwerfen.

„Auf den vorherigen Geschäftstag vorziehen“ und „N Geschäftstage davor“

Was eine Erinnerung zum Monatsabschluss tatsächlich braucht, ist nicht „jedes Monatsende“ — sondern „der vorherige Geschäftstag, falls das Monatsende ein freier Tag ist“. Das lässt sich in einem Flow, der an jedem Geschäftstag läuft, ausdrücken, indem geprüft wird, „heute ist ein Geschäftstag, und zwischen morgen und dem Monatsende gibt es keinen einzigen Geschäftstag“. Als Implementierung durchläuft man die Daten von morgen bis zum Monatsend-Datum (Ausdruck aus Kapitel 4) der Reihe nach, und sobald man einen Tag findet, der weder Wochenende noch in der Feiertags-Mastertabelle ist, schließt man „heute ist nicht der letzte Geschäftstag“ und bricht ab.

N Geschäftstage davor, wie „3 Geschäftstage vor dem Zahlungstermin mahnen“, folgt derselben Umformulierung. Ersetzen Sie „wenn es N Geschäftstage vor dem Termin wird“ durch „an jedem Geschäftstag ausführen, die Anzahl der Geschäftstage von heute bis zum Termin zählen und prüfen, ob sie mit N übereinstimmt“. Das Zählen von Geschäftstagen besteht schlicht darin, Tage zu zählen, die „kein Wochenende, nicht in der Feiertags-Mastertabelle und nicht in der Liste der betrieblichen Schließtage“ sind. Allerdings wird ein Flow-Schleifenprozess, der Daten Tag für Tag zählt, sobald der Zielfallbestand einige hundert übersteigt, zu einer Schleife aus Datensatzanzahl mal Tagesanzahl, was sowohl Laufzeit als auch API-Aufrufe aufbläht. Erreicht man diese Größenordnung, ist es gesünder, die Geschäftstagsberechnung aus dem Flow herauszuverlagern (eine Geschäftstagstabelle in einer Datenbank oder eine kleine API), oder sie als Entwicklungsterrain aus Kapitel 8 zu behandeln.

6. Erinnerungen und Mahnungen entwerfen — eine Nachricht pro Person, gebündelt

Voraussetzung: Das Verzeichnis muss bereits Daten sein

Das Mahnen überfälliger Positionen lässt sich nur automatisieren, wenn sich „was es ist, wessen Verantwortung es ist und wann es fällig ist“ als Daten abrufen lässt. Ist Ihr Verzeichnis noch eine Excel-Datei, die als E-Mail-Anhang auf einem gemeinsamen Ordner zirkuliert, sollten Sie zunächst deren Umstellung auf eine SharePoint-Liste erwägen. Im Folgenden wird eine SharePoint-Liste mit den Spalten „Fälligkeitsdatum“, „Status“ und „Zuständiger“ vorausgesetzt.

Beim Abrufen filtern

Statt alle Elemente der Liste abzurufen und dann innerhalb des Flows anhand einer Bedingung zu verzweigen, filtern Sie überfällige Positionen serverseitig mit der Filterabfrage von Get items (ein OData-Filter).¹⁴

DueDate lt '2026-07-18' and Status ne 'Complete'

Betten Sie den in Kapitel 4 aufgebauten Ausdruck „heute in japanischer Zeit“ in den Datumsteil ein. Beachten Sie, dass die Spaltennamen der Filterabfrage mit SharePoints internen Namen geschrieben werden müssen, nicht mit den am Bildschirm gezeigten Anzeigenamen, und dass standardmäßig nur 100 Elemente zurückgegeben werden, sodass eine Liste mit vielen Elementen entweder eine Top-Count-Begrenzung angegeben oder eine Paginierung konfiguriert braucht.¹⁴

Die Apply-to-each-Hölle vermeiden — wie man zu einer Nachricht bündelt

Durchläuft man die Extraktionsergebnisse direkt mit Apply to each und sendet für jedes eine E-Mail, erhält Zuständige A bei 10 unbearbeiteten Positionen jeden Morgen 10 E-Mails. Hält man das ein paar Wochen durch, werden die Benachrichtigungen garantiert nicht mehr gelesen, was den Erinnerungsmechanismus selbst tötet. Die Regel lautet: Benachrichtigungen zu einer Nachricht pro Zuständigem bündeln. Mit Datenoperationsaktionen lässt sich das im folgenden Ablauf bauen.⁷

1. Mit Select aus den Extraktionsergebnissen ein Array von Zuständigen-E-Mail-Adressen aufbauen und mit union() Duplikate entfernen, um eine „heute zu benachrichtigende Zuständigenliste“ zu erstellen⁵
2. Diese Zuständigenliste mit Apply to each durchlaufen und darin mit Filter array „nur die Positionen dieses Zuständigen“ extrahieren
3. Mit Create HTML table zu einer Tabelle aus Betreff, Fälligkeitsdatum und Status formatieren, in den Text einer E-Mail (oder Teams-Nachricht) einbetten und nur diese eine Nachricht senden (bei der E-Mail die HTML-Anzeige aktivieren⁷)

So sieht das Gesamtbild aus.

flowchart TD
    Rec[Recurrence-Trigger<br/>Werktage, 9:00 Uhr, Zeitzone: Osaka, Sapporo, Tokio] --> Today[Heute in japanischer Zeit aufbauen<br/>convertTimeZone]
    Today --> Hol{Steht heute in der Feiertags-Mastertabelle<br/>oder der Liste der betrieblichen Schließtage?}
    Hol -- Ja --> Term[Terminate, Cancelled<br/>Beenden, da kein Geschäftstag]
    Hol -- Nein --> Get[Get items<br/>Überfällige und unvollständige Datensätze extrahieren]
    Get --> Any{Gibt es Treffer?}
    Any -- Nein --> End([Ende, keine Benachrichtigung])
    Any -- Ja --> Sel[Zuständigenliste mit Select aufbauen<br/>Mit union entdoppeln]
    Sel --> Each[Schleife pro Zuständigem]
    Each --> Filter[Filter array<br/>Nur die Positionen dieses Zuständigen extrahieren]
    Filter --> Table[Mit Create HTML table zu einer Tabelle formatieren]
    Table --> Send[Eine Benachrichtigung an den Zuständigen senden<br/>Teams oder Outlook]
    Send --> Log[Ausführungsergebnis in eine Protokollliste eintragen]

Die Wahl zwischen Teams und Outlook

Wählen Sie den Benachrichtigungskanal je nach Art der Nachricht.

Die gängige Aufteilung ist Teams für tägliche Zusammenfassungen und E-Mail für formelle Erinnerungen vor dem Abschluss und Mahnungen bei Überfälligkeit. Denselben Inhalt über beide Kanäle zu senden wird nicht empfohlen, da es lediglich die Gesamtmenge der Benachrichtigungen erhöht.

So entwerfen, dass man nicht zu sehr nervt

Der beängstigendste Teil bei der Automatisierung von Erinnerungen ist, so viele zu senden, dass alle ignoriert werden. Manuelles Mahnen besitzt eine natürliche Bremse — es ist unangenehm auszusprechen, sodass die Häufigkeit gering gehalten wird —, doch ein Flow besitzt keine solche. Diese Bremse müssen Sie im Entwurf einbauen.

• Die Gesamtmenge entwerfen. Jeden Morgen, alle, alles ist das schlimmste Muster. Grenzen Sie die Sendebedingungen ein — senden Sie täglich beispielsweise nur für heute fällige oder überfällige Positionen, und beschränken Sie vorherige Erinnerungen auf nur zwei: 3 Geschäftstage vorher und den Tag davor.
• Stufen einbauen. Benachrichtigen Sie zunächst nur die Einzelperson, und nehmen Sie die Führungskraft erst als Empfänger auf, sobald die Überfälligkeit N Geschäftstage angehalten hat — teilen Sie die Eskalation so auf. Senden Sie von Anfang an alles an die Führungskraft, wird die Benachrichtigung schlicht zu Lärm.
• Einen Weg zum Stoppen einbauen. Stellen Sie stets einen Ausgang bereit, bei dem die Benachrichtigungen ab dem nächsten Tag aufhören, sobald der Zuständige die Statusspalte der Liste auf „Abgeschlossen“ setzt. Bleiben Abschlussmeldungen weiterhin nur E-Mail-Antworten, mahnt der Flow weiter, und der Zuständige entwickelt Groll gegen den Flow.
• „Keine Benachrichtigung bedeutet kein Problem“ vertrauenswürdig halten. Das gilt nur zusammen mit der im nächsten Kapitel behandelten Überwachung.

7. Betriebliche Vorsichtsmaßnahmen — man kann nicht erkennen, wann ein zeitgesteuerter Flow gestoppt hat

Bei einem ereignisgesteuerten Flow bemerkt die Fachseite, wenn „ich habe den Antrag eingereicht, und er ist nicht gelaufen“. Ein zeitgesteuerter Flow besitzt keinen solchen Detektor. Ist die Monatsend-Erinnerung gestoppt, verzögert sich der Abschluss einfach, ohne dass jemand etwas sagt. Bauen Sie Ihr Betriebsdesign auf folgenden Spezifikationen auf.

• Es gibt Bedingungen, unter denen sich ein Flow automatisch abschaltet. Ein Flow, dessen Trigger oder Aktionen fortlaufend fehlschlagen, schaltet nach 14 Tagen ab, und ein Flow, der fortlaufend gedrosselt wird, schaltet ebenfalls nach 14 Tagen ab. Zusätzlich kann ein Flow, der 90 Tage lang kein einziges Mal ausgelöst wurde, abgeschaltet werden (das gilt nicht für einen Flow, dessen Besitzer eine Premium- oder eine Kapazitätslizenz wie Process besitzt; Besitzer und Mitbesitzer werden 30 Tage vor der Abschaltung benachrichtigt, und Sie können ihn wieder einschalten, um ihn fortzusetzen).⁸ Bauen Sie einen „Flow, der nur einmal pro Quartal läuft“, achten Sie auf diese 90-Tage-Regel.
• Standardmäßig sind nur 28 Tage des Ausführungsverlaufs sichtbar.⁹ Bei einem monatlichen Flow bedeutet das rechnerisch, dass sich nur die jüngste einzelne Ausführung prüfen lässt. Fügt man am Ende des Flows einen Schritt hinzu, der eine Zeile — „Ausführungsdatum/-zeit, Anzahl verarbeiteter Datensätze, Ergebnis“ — an eine Protokoll-SharePoint-Liste anhängt, lässt sich „ist es letzten Monat tatsächlich gelaufen“ unabhängig vom Ablauf des Ausführungsverlaufs prüfen. Deshalb steht der Protokollierungsschritt am Ende des Diagramms in Kapitel 6.
• Geben Sie dem Flow selbst eine Möglichkeit, Fehlschläge zu bemerken. Ohne eine Verzweigung, die einen Administrator bei Fehlschlag benachrichtigt (eine Aktion mit der Ausführungsbedingung „ist fehlgeschlagen“), bemerkt niemand einen Fehlschlag während der gesamten 14 Tage bis zur Abschaltung. Den Aufbau von Fehlerbehandlung und Wiederholungen behandeln wir ausführlich in Fehlerbehandlung und Retry-Design in Power Automate.
• Das Ausscheiden oder der Wechsel des Besitzers stoppt den gesamten Zeitplan. Ein Flow mit Recurrence-Trigger läuft über die Verbindung des Flow-Erstellers.¹¹ Wird das Konto des Besitzers deaktiviert, bricht die Verbindung ab, der Flow beginnt zu scheitern und schaltet sich schließlich ab. Richten Sie Mitbesitzer und eine Bestandsaufnahme der Verbindungen bereits am ersten Tag des Produktivstarts ein.¹⁶ Besitz, Verbindungen und Übergabedokumentation sind einen eigenen, gezielten Entwurf wert, kein Thema, das man erst klärt, nachdem jemand schon gegangen ist.
• Die Zeit, in der er abgeschaltet war, wird nie nachträglich ausgeführt (Fallstrick 6 in Kapitel 3). Schalten Sie einen Flow für Wartung oder Störungsbehebung ab, prüfen Sie das nächste geplante Ausführungsdatum und legen Sie vorab einen manuellen Ausführungs-Fallback für Fälle fest, in denen Sie es doch überspannen.¹⁰

8. Wie weit sollte man mit Power Automate gehen

Zeitgesteuerte Ausführung ist ein hervorragender Einstiegspunkt in die Automatisierung, doch alles und jedes, was „periodisch läuft“, zu einem Flow zu machen, ist gefährlich. Hier ein grober Anhaltspunkt für die Grenzziehung.

Als Faustregel liegt die Grenze etwa hier: Power Automate bis hin zum „jemanden bemerken lassen“, Entwicklung für das „Festschreiben“ (Umschreiben von Kerndaten des Systems). Wir haben mehr als einmal Fälle gesehen, in denen der Versuch, den Abschlussprozess selbst als Flow zu bauen, in eine Explosion von Verzweigungen mündete, und die Dinge stabilisierten sich meist, sobald man es wieder aufteilte in „der Abschluss selbst läuft auf dem bestehenden System oder über Auftragsentwicklung, und nur die Erinnerung, die das Vergessen des Abschlusses verhindert, bleibt als Flow“. Auch für wiederkehrende Verarbeitung, die vollständig innerhalb eines Servers abläuft, ohne über die Cloud zu gehen, können PowerShell und die Aufgabenplanung mitunter einfacher und leichter zu warten sein. Der Vergleich, wann was zu verwenden ist, ist ein Thema, das einen eigenen Artikel wert ist.

9. Zusammenfassung

Der eigentliche Kern beim Entwurf eines zeitgesteuerten Flows liegt weniger in der Konfiguration des Recurrence-Triggers selbst als in dem, was davor und danach kommt. Davor steht die Ausformulierung des stillschweigenden Wissens „nach Kalenderbeobachtung handeln“ zu einer expliziten Spezifikation: Was passiert, wenn das Monatsende auf einen Feiertag fällt, wer trägt Feiertage wann in die Mastertabelle ein. Ein Flow, der gebaut wird, ohne dies zu klären, wird gegenüber dem japanischen Kalender früher oder später immer fehlfunktionieren. Danach steht die betriebliche Praxis, um zu bemerken, wenn er gestoppt hat: ein 28-tägiger Ausführungsverlauf, die verschiedenen Bedingungen zur automatischen Abschaltung, ein Zeitplan, der stoppt, wenn der Besitzer ausscheidet. Bauen Sie Fehlerbenachrichtigungen und ein Ausführungsprotokoll von Anfang an ein, unter der Annahme, dass ein zeitgesteuerter Flow lautlos stoppt.

Die technischen Kernpunkte lassen sich auf drei bringen: die Zeitzone ausdrücklich festlegen (der Standard ist UTC), Daten in japanische Zeit umwandeln, bevor sie geprüft werden, und Feiertage in einer Mastertabelle führen und Nicht-Geschäftstage mit einer Schranke am Anfang des Flows zurückweisen. Haben Sie diese drei einmal im Griff, bündeln Sie Benachrichtigungen nach Zuständigem und geben Sie Mahnungen sowohl Stufen als auch einen Ausgang. Tun Sie das alles, lässt sich ein erheblicher Teil der „Arbeit, bei der eine Person nach Kalenderbeobachtung handelt“, durch einen zeitgesteuerten Flow ersetzen, dem man vertrauensvoll die selbstständige Ausführung überlassen kann. Und sobald Sie sich dabei ertappen, in „festschreibende“ Verarbeitung vordringen zu wollen — wie den Abschlussprozess oder Kernsystem-Batch-Jobs —, ist das der Moment, den Wechsel ins Entwicklungsterrain in Betracht zu ziehen.

Verwandte Artikel

• Geschäftsprozesse mit Power Automate automatisieren — Cloud-Flows, Desktop-Flows und robuste Fehlerbehandlung
• Japanische Ären-Daten, Feiertage und Abschlusstermin-Verarbeitung in Geschäftsanwendungen — ärenresistentes Design, JapaneseCalendar und Geschäftstagsberechnungen in der Praxis
• Fehlerbehandlung und Retry-Design in Power Automate

Verwandte Beratungsbereiche

Die KomuraSoft LLC übernimmt alles von Design-Reviews zeitgesteuerter Verarbeitung und Erinnerungen, die mit Power Automate gebaut wurden, bis zur Entwicklung von Abschlussprozessen, Geschäftstagsberechnungen und Kernsystem-Integrations-Batch-Jobs, die über das hinausgehen, was ein Flow bewältigen kann.

• Technische Beratung & Design-Review
• Windows-App-Entwicklung
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wie lasse ich einen zeitgesteuerten Power-Automate-Flow jeden Morgen um 9 Uhr japanischer Zeit laufen?

Wählen Sie im Zeitzonenfeld des Recurrence-Triggers „(UTC+09:00) Osaka, Sapporo, Tokio“ und geben Sie die Startzeit an. Geben Sie keine Zeitzone an, wird die Startzeit als UTC mit angehängtem Z behandelt, sodass eine als „9:00“ gedachte Einstellung tatsächlich um 18 Uhr japanischer Zeit läuft. Auch utcNow() innerhalb von Ausdrücken gibt immer UTC zurück, sodass Sie „das heutige Datum“ innerhalb eines Flows zunächst mit etwas wie convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd') in japanische Zeit umwandeln müssen.

Besitzt Power Automate eine Funktion zur Erkennung japanischer Feiertage?

Es gibt keine integrierte Funktion. Die Wochentagseinstellung des Recurrence-Triggers ermöglicht die Ausführung „nur an Werktagen“, berücksichtigt jedoch keine Feiertage, und auch in der Liste der Ausdrucksfunktionen gibt es keine, die Feiertage zurückgibt. In der Praxis baut man eine eigene Mastertabelle mit Feiertagsdaten (etwa eine SharePoint-Liste), durchsucht sie gleich am Anfang des Flows danach, ob „heute in der Mastertabelle steht“, und beendet den Flow, falls es kein Geschäftstag ist. Zur Aktualisierung der Mastertabelle kann die vom Kabinettsbüro veröffentlichte Feiertags-CSV als Primärquelle dienen.

Kann ich einen Flow bauen, der nur am letzten Geschäftstag des Monats läuft?

Bei einem festen Datum wie „jeden 20. des Monats“ können Sie das Start-Datum/die Startzeit auf das Zieldatum setzen und die Häufigkeit auf „Monat“ stellen, wodurch eine Ausführung entsteht, die jeden Monat, ausgehend vom Start-Datum/der Startzeit, an demselben Tag zur selben Uhrzeit erfolgt. Andererseits besitzt der Recurrence-Trigger keine Option, um „den letzten Tag des Monats“ direkt anzugeben, und detaillierte Einstellungen für Wochentag oder Uhrzeit sind nur verfügbar, wenn die Häufigkeit „Tag“ oder „Woche“ ist. Für Verarbeitungen, bei denen sich das Datum verschiebt, wie am Monatsende, bauen Sie den Flow so, dass er jeden Tag (oder jeden Werktag) läuft, lassen einen Ausdruck ganz am Anfang entscheiden, ob „heute der letzte Tag des Monats ist“ oder „heute ein Geschäftstag ist“, und beenden den Flow an jedem Tag, der die Bedingung nicht erfüllt. Die Monatsend-Prüfung lässt sich als „heute ist der letzte Tag des Monats, wenn sich der Monat von heute und morgen unterscheidet“ ausdrücken. „Am letzten Geschäftstag ausführen, wenn das Monatsende auf ein Wochenende oder einen Feiertag fällt“ wird ausgedrückt, indem man derselben Struktur eine Prüfung der Feiertags-Mastertabelle hinzufügt.

Mein zeitgesteuerter Flow hat sich abgeschaltet, ohne dass ich es bemerkt habe. Warum ist das passiert?

Power Automate besitzt mehrere Bedingungen, die einen Flow automatisch abschalten. Ein Flow, dessen Trigger oder Aktionen fortlaufend fehlschlagen, wird nach 14 Tagen abgeschaltet, und ein Flow, der fortlaufend gedrosselt wird (Limits überschreitet), wird ebenfalls nach 14 Tagen abgeschaltet. Zusätzlich kann ein Flow, der 90 Tage lang kein einziges Mal ausgelöst wurde, abgeschaltet werden (dies gilt nicht, wenn der Besitzer eine Premium- oder Kapazitätslizenz besitzt, und Besitzer sowie Mitbesitzer werden 30 Tage vor der Abschaltung benachrichtigt). Da es für alle schwer zu bemerken ist, wenn ein zeitgesteuerter Flow aufhört zu laufen, ist es wichtig, von Anfang an Fehlerbenachrichtigungen und einen Ausführungsnachweis einzubauen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.