Gründe gegen einen Approval Task in SharePoint Designer Workflows

SharePoint Designer unterstützt Technik-Affine Mitarbeiter dabei, einfache Workflows für die Prozesse im Unternehmen umzusetzen. Es gibt verschiedenen Aktionen, die man auswählen und konfigurieren kann. Eine davon ist der sogenannet Approval Task.

Der Approval Task ist wie eine Vorlage und erstellt eine Aufgabe und weist diese einem Benutzer zu. Er wartet auf eine Aktion des Benutzers oder bis eine definierte Zeitspanne abgelaufen ist und bearbeitet dann weitere Schritte. Je nach Aktion des Benutzers liefert er ein konfiguriertes Ergebnis zurück und kann auch aus den Aufgaben heraus automatisiert dann in das SharePoint Element, auf dem der Workflow gestartet wurde, Werte zurückschreiben.

Wenn jemand den Workflow startet (bspw. Benutzer A), dann läuft dieser im Kontext des Benutzers A. Sobald nun die Aufgabe an einen weiteren Benutzer B geleitet wird und dieser Werte vervollständigen soll und die Aufgabe abschließt, läuft der Workflow immer noch im Kontext des Benutzers A. Somit sind alle Änderungen, die am workflow-startenden Element durchgeführt werden, als Änderungen von Benutzer A markiert anstelle von Benutzer B.

Jeder Approval Task beinhaltet InfoPath Formulare. Bei der Anpassung der InfoPath Formular muss man sehr genau aufpassen, da ansonsten eine Veröffentlichung des Workflows nicht mehr funktioniert.

Wenn man auf den Approval Task verzichten möchte, ist die Aktion “Warten auf eine Feldänderung” eine gute Alternative. Hierbei sollte man sich vorab kurz Gedanken machen. Denn bei dieser Aktion muss man das Feld und den erwarteten Wert des Feldes angeben. Der Workflow wartet dann solange, bis das Feld genau dieses Ergebnis erreicht.

Der Nachteil ist, wenn man auf Basis von Statuseinträgen diese Funktion nutzt. Typischerweise bei einem Antrag gibt es den Status In Bearbeitung, Freigegeben und Abgelehnt. Das bedeutet also, wenn man darauf wartet, dass das Feld Status den Wert auf Freigegeben wechselt, der Benutzer aber Abgelehnt hat, dann endet der Workflow nie.

Ein Workaround an der Stelle ist, wenn man für jeden Status ein verstecktes Feld nutzt, in den man für jede Phase eine Zahl eingibt:

0 = Phase: Start – Status In Bearbeitung

1= Phase: Freigabe / Ablehnung – Status Freigegeben oder Abgelehnt

Nun kann man im Schritt darauf warten, dass das Feld Phase von 0 auf 1 springt und dann abfragen, welchen Status das Element hat – Abgelehnt oder Freigegeben. Je nach Status kann dann die entsprechende Aktion gestartet werden.

The article or information provided here represents completely my own personal view & thought. It is recommended to test the content or scripts of the site in the lab, before making use in the production environment & use it completely at your own risk. The articles, scripts, suggestions or tricks published on the site are provided AS-IS with no warranties or guarantees and confers no rights.

About Karsten Schneider 312 Articles
Consultant for Microsoft 365 Applications with a strong focus in Teams, SharePoint Online, OneDrive for Business as well as PowerPlatform with PowerApps, Flow and PowerBI. I provide Workshops for Governance & Security in Office 365 and Development of Solutions in the area of Collaboration and Teamwork based on Microsoft 365 and Azure Cloud Solutions. In his free time he tries to collect tipps and worthy experience in this blog.

Be the first to comment

Leave a Reply

Your email address will not be published.


*