Wird SharePoint on-premise betrieben, können Nintex Workflow Tasks (generell Tasks) an andere Personen delegiert werden. Dazu kann auf dem Task Formular ein Link aktiviert werden, über den der Besitzer des Tasks diesen weiterleiten kann (Beispielsweise falls der Task ihm fälschlicherweise zugewiesen wurde).
Ergänzend kann der Benutzer über die Site Einstellungen eine Art Abwesenheitszeitraum definieren. Während dieses Zeitraums werden alle an ihn gerichteten Tasks automatisch an die zuvor benannte Person delegiert. Praktisch bei Urlaub oder längerer Krankheit.

Dies ist leider im Kontext von SharePoint Online nicht möglich. Hier gibt es weder in den SharePoint Tasks, noch bei den Nintex Tasks (welche letztlich die SharePoint Tasks als Basis verwenden) eine Möglichkeit der Delegation.

Lösung einfacher Fall

Die meisten Tasks versenden sicherlich eine E-Mail an den Besitzer, damit dieser über die neue Aufgabe informiert ist. Die einfachste Lösung ist, diese Mail an eine andere Person weiterzuleiten. Sofern der Empfänger über die gleichen Berechtigungen verfügt, kann dieser die Aufgabe ebenfalls abschließen. SharePoint prüft beim Bearbeiten einer Task nicht, ob der Besitzer oder eine andere Person die Aufgabe bearbeitet.

Problematisch wird es dann, wenn der Empfänger der Mail nicht die erforderlichen Berechtigungen inne hat. Dies kann z.B. er Fall sein, wenn man die Berechtigungen auf Elementebene vergibt.

Lösung komplexer Fall

Beispiel komplexer Fall

Vertriebsmitarbeiter können Gutschriften für Kunden beantragen, etwa wenn dieser Kunde bei Vertriebstätigkeiten unterstützt hat (Messeauftritt des Kunden und Präsentation des eigenen Produkts). Die gestellten Anträge müssen vom Innendienst genehmigt werden.

Alle Außendienstmitarbeiter arbeiten zur Beantragung mit einer SharePoint Site, welche einen entsprechenden Workflow auf Listenelemente ausführt (List Workflow).

Um keine Begehrlichkeiten unter den Mitarbeitern zu wecken, darf jeder Antragsteller nur die Anträge sehen, die er selbst gestellt hat. Gleiches gilt für die Genehmiger, welche nur die Anträge sehen, die sie zu genehmigen haben.

Mit Erstellen eines Antrags wird die Berechtigungsvererbung des Antrags (das Listenelement) unterbrochen und das Element mit eigenen Berechtigungen ausgestattet.

In diesem Fall kann der Genehmiger nicht einfach die Task E-Mail weiterleiten. Da der Empfänger keine ausreichende Rechte hat, kann er zwar auf das Task Formular zugreifen, dieses wird aber nicht vollständig geladen, da er keinen Zugriff auf das eigentliche Listenelement hat.

Lösung

Dies kann durch einen weiteren Workflow gelöst werden. Dieser Workflow (im folgenden Delegationsworkflow genannt) nimmt im Startformular einen Namen entgegen. Anschließend werden die Berechtigungen des bisherigen Genehmigers entfernt und der neue Besitzer berechtigt.

Der Workflow wird mit den Berechtigungen des Workflow Initiators ausgeführt. Der Initiator hat in der Regel keine Rechte, Berechtigungen zu verwalten. Folglich kann der Workflow mit diesen Rechten nicht ausgeführt werden.

Zunächst wird daher ein Action Set definiert, welches mit App-Berechtigungen (evelated privileges) ausgeführt wird

Anschließend werden die Berechtigungen mit der Action "Office 365 update items" bereinigt.

Zunächst werden die Rechte des bisherigen Genehmiger entfernt. Der Genehmiger selbst ist in einer Spalte in dem Antrag gespeichert und somit leicht zu ermitteln.

Das Ergebnis der Berechtigungsaktion wird in einer Variablen gespeichert

Und später im Log ausgegeben.

Im nächsten Schritt wird der neue Genehmiger in das Feld des Antrags übernommen. Durch die Versionierung ist später nachvollziehbar, wer der ursprüngliche Genehmiger war.

Anschließend wird der neue Genehmiger berechtigt. Dies geschieht analog zur vorherigen Berechtigungsaktion

Ab diesem Zeitpunkt kann der neue Genehmiger den Task bearbeiten. Der eigentliche Workflow Task muss dazu nicht bearbeitet werden. Hier steht nach wie vor der bisherige Genehmiger als Besitzer. Sofern die Tasks keine Elementberechtigungen verwenden (was ich nicht empfehle), kann der neue Besitzer den Task öffnen und dank der neuen Rechte auch anzeigen. In der Workflow History kann geloggt werden, wer den Task tatsächlich beendet hat.

Die hier gezeigte Lösung ist keinesfalls ein vollwertiger Ersatz für die bisherige Delegation. Zum einen muss der Delegationsworkflow pro Element manuell gestartet werden. Zum anderen ist dies nicht sonderlich intuitiv. Geplante Abwesenheiten lassen sich über einen separaten Site Workflow realisieren. Dazu kann man die Abwesenheiten in einer Liste sammeln und alle x-Stunden prüfen, ob jemand abwesend ist.

Somit kann man sich zumindest mit einem Workaround behelfen.