Dieser Use-Case ist auf dem PM-Forum 2024 im Workshop 2 entstanden und stellt das Handling von Terminanfragen dar.
Jedoch nur auf den ersten Blick, wir haben vor-Ort sehr viel über diesen Use-Case diskutiert, den auf den ersten Blick erscheint der Case zwar simpel… aber im Detail verbergen sich hier enorme Fallstricke:

Prozessschritte und Lösungsansatz
Es kann automatisiert werden 🙂 aber da steckt viel Arbeit drin 😉
Als erstes muss der Ablauf in verschiedene Workflows aufgetrennt werden:
Datenbasis
Der Workflow benötigt aber eine Datenbasis, in diesem Beispiel habe ich Excel dafür verwendet.

Es wird die Anfrage in der XLS erfasst und der Zielzeitraum. In diesem Zielzeitraum setzt Power-Automate die Blocker. Bei den notwendigen Teilnehmer:innen wird durch X entsprechenden TN ausgewählt.
Hier könnte man auch durch die Angabe X (Sybille) eine zusätzliche Logik einbringen:

Damit würde Power-Automate prüfen, ob Sybille zugesagt hat, aber Sepp nicht => der Termin kann trotzdem stattfinden.
Nach der Anlage des Eintrages erstellt die XLS einen Reiter mit der ID des Termins und der Übersicht der möglichen Buchungen:

In diesem Reiter findet das eigentliche Tracking statt.
Workflow 1 – Terminblocker versenden

Dafür ist es notwendig, dass der Terminkalender der zu prüfenden Personen freigegeben wurde.
Dieser Workflow würde manuell (Klick auf Button) gestartet.
Die Funktion, die dafür benötigt wird, lautet „Termine abrufen“:

und die entsprechende Schleife, die jeden der Einträge aus der XLS prüft.
Nachdem die Blocker versendet worden sind, wird die XLS Datei angepasst:

Der Workflow 1 benötigt hier eine Ausstiegsklausel und zwar wenn alle möglichen Slots in dem Zeitraum geprüft wurden, informiert er die definierte Person mit dem Hinweis „Keine Termine möglich, bitte anderen Zeitraum auswählen“.
Workflow 2 – Gibt es Slots die möglich sind

Dieser Workflow wird stündlich gestartet und damit werden die Antworten ausgewertet und die XLS Datei befüllt:

Sollten es mögliche Slots geben, wird eine definierte Person benachrichtigt, damit dort manuell die Information an den Kunden gesendet werden kann.
Gibt es keinen Slot, findet eine erneute Prüfung durch den Workflow 1 statt.
Dabei werden die Vorschläge in der Tabelle ergänzt, um nicht die gleichen Slots wieder zu verwenden.

Damit der WF1 nicht in eine Schleife gerät, wird die oben erwähnte Ausstiegsklausel in WF1 benötigt.
Feedback des Kunden, ob der Termin passt
Das Feedback wird manuell vom Organisator eingetragen:

Durch die Eingabe in der Spalte F kann Power-Automate dieses auswerten.
Workflow 3 – Termin passt und es geht weiter
Das Löschen der restlichen Blocker und die Umwandlung des Termins übernimmt dieser Workflow:

Persönliche Empfehlung
Ich würde noch einen weiteren Workflow als Bereinigungsworkflow stündlich laufen lassen. Die Aufgabe dieses Workflows wäre die Blocker, die nicht zu einem Termin werden können, zu löschen.
Man könnte es auch als Reinigungsworkflow bezeichnen 😉