Ein häufiges Szenario in Power Automate ist das Setzen eines Status. Hierzu folgende Annahmen:
- Datenquelle SharePoint Liste
- Power Automate mit einem Trigger („When an item is created or modified“)
- Innerhalb des Listenelements bzw. eine Spalte in der Liste dient dem Status, z.B. für ein Approval (Neu, Genehmigt, Abgelehnt)
- Power Automate holt die Genehmigung oder setzt aus sonst irgendwelchen Gründen Felder im gleichen Listenelement.
Was jetzt passiert, in dem Moment wenn Power Automate das eigene Listenelement aktualisiert, wird wieder ein Trigger ausgelöst und der Flow startet sich selbst – in Endlosschleife.
Mittlerweile kommt auch eine Warnung im Flow checker:
Jede Ausführung geht gegen das Tenant Quota und kann hier zu dramatischen Auswirkungen führen.
Ich gehe davon aus, dass der Flow mit einem Service Account ausgeführt wird, und eigentliche Änderungen durch normale Benutzer initiiert werden. Daher nehme ich im Folgenden den Service Account aus.
Eine Variante wäre per If Statement den „zuletzt geändert von“ zu überprüfen, das kostet aber einen wertvollen Flow Run für nichts.
Trigger Condition
Besser ist hier die Trigger Condition, hier wird die Bedingung geprüft, noch bevor der Flow überhaupt gestartet wird. Hier kann man also relativ einfach mit folgenden Code den SharePoint (zuletzt geändert von) ausnehmen:
@not(equals(triggerOutputs()?['body/Editor/Email'],'workflow@contoso.com'))
Hier die „Settings“ über den Trigger bearbeiten:
Anschließend kann der o.g. Code eingefügt werden – in dem Beispiel den UPN hinterlegen:
Wer den Code oder andere Bedingungen benötigt, kann am besten per „Compose“ den eigenen Code zusammenstellen, testen und anschließend als Trigger Condition übernehmen. Als Ergebnis wird „true“ für einen Start erwartet.
Fazit
Mithilfe der TriggerCondition kann die Workflow Ausführung unterbunden werden und so wertvolle Flow Runs gespart werden. Im Troubleshooting drauf achten, denn Änderungen durch den o.g. Account werden gar nicht gestartet und sind auch nicht ersichtlich.
