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.