PowerAutomate als Service

Routinetätigkeiten möchte man auch als Anwender gerne automatisieren und Power Automate kann dafür sehr nützlich sein. Per Maus und Low Code kann ein Anwender eigene Abläufe automatisieren. Dies gilt z.B. wenn die Outlook Posteingangsregeln nicht mehr ausreichen. Aber sind Power Automate dafür geeignet?

PowerAutomate mit Mails

Als Beispiel möchte ich mir persönlich eine Automatisierung anlegen die etwas mit einer "Shared Mailbox" für mich macht das geht unter https://make.powerautomate.com/ relativ schnell. Sie brauchen ja nur einmal nach "Outlook" suchen und finden jede Menge Vorlagen, die sich aber nicht nur auf Exchange Online sondern auch Outloook.com oder andere Dienste beziehen

Prozesse in PowerAutomate können durchaus auch fremde Dienste anzapfen. Ich bleibe aber in der Microsoft 365-Welt und lege einen neuen Flow basierend auf "Post message to Teams when an email arrives in Office 365 Outlook" an. Dies ist ein "Automated"-Prozess, d.h. er wird automatisch gestartet, wenn eine neue Mail kommt.

Alternativ gibt es dazu auch den Typ "Scheduled", bei dem sie eine zyklische Ausführung konfigurieren können oder den Flow einfach manuell ausführen.

Der Flow benötigt natürlich eine Verbindung zu meinem Postfach und zu Teams. Das wird über Konnektoren konfiguriert, die ich im nächsten Schritt legitimieren muss.

Der aus dem Template angelegte Flow ist sehr einfach zu verstehen. Ich habe hier die Bedingung einmal geöffnet

Ich kann den Flow Anpassung am Ende muss ich ihn oben nur noch mit "Save" speichern. Natürlich sollte ich ihn auch testen. Aber der Schwerpunkt dieser Seite liegt nicht im Programmieren mit Power Automate, sondern was das für eine Firma konzeptionell bedeutet. Der Flow liegt nämlich in meinem "Persönlichen" Arbeitsbereich und der ist weg, wenn mein Konto entfernt wird. Die Aktivitäten gehen von meinem Budget ab und je nach Lizenz gibt es Grenzwerte. Spätestens jetzt sollten sie sich überlegen, ob hier nicht wieder eine neue "Schatten-IT" entsteht, dass nämlich Anwender eigenständig Prozess in Power Automate umsetzen, die nicht mehr persönlich sondern für das Team, die Abteilung, den Standort oder die gesamte Firma relevant sind. Dann sollten solche kritischen Prozesse nicht im persönlichen Bereich eines Anwenders ohne Dokumentation oder Überwachung laufen.

Microsoft versteckt dies nicht, sondern schreibt es direkt auf "Getting started".

Als Administrator sollten sie daher entsprechenden Bereich bereitstellen, damit Anwender alle Flows, die nicht persönlicher Natur sind, entsprechend gleich am richtigen Platz veröffentlichen.

Eine zweite  Einstellung ist die Frage der Besitzer und der CoOwner. Auf der Übersicht zum gerade angelegten Flow ist unter den Connectoren auch diese Information zu sehen:

Sie können hier steuern, wer aus ihrer Firma noch den Flow sehen, bearbeiten und kontrollieren kann.

Allen Anwendern sollte daher bekannt sein, wie sie Flows anlegen und bereitstellen sollten, ehe Sie eine Flow-Lizenz bekommen.

Eine Konzeption zur Umsetzung von persönlichen, teamweiten oder sogar unternehmensweiten Flows ist keine schlechte Idee. Das betrifft die Festlegung, wer Flows anlegt und entwickelt, wer z.B. vom Unternehmen bereitgestellte Flows übernehmen kann, wo diese Flows abgespeichert und vor allem auch mit welcher Lizenz (Free, Premium, Subscription) und Berechtigungen die ausgeführt werden.

Allerdings würde dies den Umfang der Seite sprengen. Bei Bedarf können Sie meine Kollegen oder mich gerne ansprechen.

Power Automate mit Service Principal

Als Administrator sollten sie wissen, dass mit der richtigen Lizenz ein Flow auch mit einem "Service Principal" als Owner und ausführende Identität hinterlegt werden kann. Dann kann der Flow unabhängig von einem Benutzer aktiv sein und hat mehr den Charakter eines "Dienstes" mit einem Dienstkonto ohne jedoch die Sicherheit einen interaktiven Anmeldekontos und die MFA-Anforderungen zu schwächen.

Allerdings kann ein solches Konto z.B. keine "Microsoft 365  E3/E5"-Lizenz bekommen, da es kein Mensch ist. Wir müssen uns also über alternative Lizenzen für Flows unterhalten. Microsoft bietet z.B. Pakete für diese Aufgabenstellung an. Ein Paket für bis zu 5 Flows kostet ca. 100€/Monat. Die erforderliche Rechenleistung geht dann natürlich nicht von einem Benutzer ab. Viel wichtiger ist aber, dass solche Flows dann wirklich unabhängig von Benutzern sind und Sie beim Exit-Prozess von Anwendern diese Abhängigkeit nicht mehr beachten müssen. Ich denke hier wieder an einen Flow, der eine Shared Mailbox bearbeitet.

Graph und Polling

Nun kann es natürlich sein, dass Sie mit Flow doch nicht alles umsetzen können oder die Lizenzen nicht attraktiv sind. Sie können dann natürlich mit eigenen Programmen und Skripten eine ähnliche Funktion bereitstellen. Das ist natürlich nicht mehr so einfach wie ein Flow im Browser "zusammen zu schieben".

Was heute dann ein "Schedules Flow" ist, wäre dann ein PowerShell-Script, welches sie auf einem Windows Server oder auch als Azure Function regelmäßig aufrufen lassen. Die meisten Quellen und Ziele lassen sich so einbinden. Natürlich braucht ihre Lösung dann auch wieder entsprechende Berechtigungen und dazu gibt es zwei Wege:

  • Delegate Access
    Ihr Prozess greift auf die Daten mit den Berechtigungen eines Anwender oder Dienstkontos zu, welches zumindest beim Zugriff auf Microsoft 365 Daten per Conditional Access oder MFA abgesichert sein muss und ihr Skript sollte mit einer eigenen AppId und den entsprechenden Berechtigungen (Content nicht vergessen) auf die Daten zugreifen
  • Application Access
    Sie legen eine EntraID Application mit AppID (=Username) und App Secret (Zertifikat oder Kennwort) an, welche dann die App-Permissions (Admin Consent) bekommt. Mit Blick auf Exchange können Sie einige Berechtigungen über eine Graph ApplicationAccessPolicy auf bestimmte Postfächer und Benutzer beschränken.

Für den Zugriff auf andere Dienste und Quellen müssen Sie ihrem Dienstkonto oder Applikation natürlich separat berechtigen.

Beim Polling ist natürlich immer die Herausforderungen, wie Sie "Delta-Abfragen" machen. Bei jedem geplanten Lauf einfach alle Objekte immer neu einzulesen und auf Änderungen zu untersuchen ist für alle Beteiligten aufwändig. Besser ist es, wenn die Gegenstelle eine Differenzabfrage unterstützt. Dies ist gar nicht mal so selten. Schon das Active Directory kann seit Windows 2000 über die aufsteigenden USNs oder eine leistungsfähigere DirSync-API überwacht werden. Auch Exchange OnPremises mit EWS, Exchange Online per Graph und Microsoft Teams mit Webhooks kennen solche Funktionen.

Graph und Change Notification

Wenn es aber "mehr Echtzeit" sein soll, dann können Sie über Graph sehr viele Microsoft 365 Datentöpfe auch über "Change Notifications" ansprechen. Ihre Lösung fordert von Microsoft Graph eine aktive Benachrichtigung an, wenn sich etwas tut. Dieses Verfahren ist weder neu noch selten. Die Teams Bots sind auch nicht anderes als Webservices, die vom Teams Backend angesprochen werden. So einen Webservice müssen Sie natürlich betreiben. Das könnte ein lokaler Webserver, eine Webseite in der Cloud oder einem anderen Hoster oder auch eine Azure Function sein, die auf eingehende Meldungen wartet und entsprechend reagiert. Sie müssen nur regelmäßig die Benachrichtigung auffrischen, da die Cloud so sicherstellt, dass sie nicht ewig nicht mehr erreichbare Dienste antriggern möchte

Lernkurve

Ich möchte sie gewiss nicht davon abhalten, mit Power Automate als Anwender oder Admin die ersten Schritt zu gehen. Jede Art von Automatisierung ist ein Fortschritt, denn speziell manuell durchzuführende Routinetätigkeiten sind teuer, fehleranfällig und letztlich auch nervig für die Person, die es tun muss. Power Automate ist eine sehr einfache Plattform, mit der Sie erste Schritte in die Automatisierung mit Microsoft 365 gehen können, ohne sich Gedanken über Server, Taskplaner, PowerShell-Script, Berechtigungen etc. machen zu müssen.

Aber das ist auch das größte Risiko: Anwender, die mit Power Automate nicht mehr nur ihre eigenen Daten verarbeiten sondern auch andere Datentöpfe anzapfen und quasi unbemerkt Prozesse entwickeln, von denen die IT-Abteilung oder die Firma als solches keine Informationen hat. Das Geschrei ist groß, wenn die Aktionen stark zunehmen und das Budget des individuellen Benutzers aufgebraucht ist, Flows einen Fehler verursachen und ein Administrator aufgrund der Unkenntnis über den Flow in Audit-Logs und anderen Stellen ratlos nach Spuren sucht oder nach dem Ausscheiden des Anwender mit Verlust des Flows eine komplette Funktion unwiederbringlich verloren geht. Ihr Aktionsplan wäre dann:

  • Steuern Sie, wer Power Automate nutzen kann
    Das kann z.B. über die Lizenz erfolgen.
  • Werten sie die Nutzung on Power Automate aus
    Dazu gibt es Power Automate Analytics: View analytics for cloud flows https://learn.microsoft.com/en-us/power-platform/admin/analytics-flow  
  • Steuern sie aus jeden Fall die Konfiguration und Ablage der Flows
    Der persönliche Arbeitsbereich ist kein guter Platz für Unternehmensprozesse
  • Legen sie regelmäßige Kopien/Exports von Flows an
    Vielleicht sogar in einem Git mit Versionssicherung
  • Prüfen Sie die Möglichkeiten einer Überwachung
    Sie können sehen, welche Flows gelaufen sind und welche ggfls. Fehler produzieren
  • Schulen und unterweisen Sie die Mitarbeiter die Power Automate nutzen
    Damit die Anwender mit einer Lizenz sich an ihre Vorgaben auch halten können.
  • Kenne die Grenze eines Flows
    Power Automate macht Azure Functions, PowerShell Skripte mit Taskplaner oder "richtige Produkte" nicht überflüssig. Erkennt die Grenzen, wann ein Flow nicht mehr sinnvoll ist

Das sind nur ein paar Überlegungen, die sie berücksichten sollen

Hinweis:
Wenn Sie mit Power Automate z.B. Exchange Objekte provisionineren wollen, dann binden Sie die Fachleute früh ein. Es kostet ihr Geld, wenn ich z.B. erst spät gefragt werden, warum ein Flow nicht wie erwartet funktioniert. Oft ist es nicht ein kleiner Parameter sondern prinzipielle Fehler, die dann einen großen Umbau oder Neudesign erforderlich machen, z.B. Wenn sie Exchange und Lizenzen verwalten und doppelte Postfächer bekommen oder sie nur die Exchange Mailbox löschen wollen aber ADSync die Microsoft 365 Identität komplett löscht, weil ein Disable-* auch die ExtensionAttribute löscht, die so gerne für ADSyncFilter genutzt werden.

Wenn sie nun gar nicht mehr wissen, wo ihnen der Kopf steht, dann suchen Sie sich einen Partner der mit ihnen gemeinsam das Thema bearbeitet.
z.B. Net at Work

Weitere Links