Hallo zusammen, vielen Dank für eure Antworten! Die Vorschläge sind normalerweise die Lösung zu meinem Problem. Leider, wie soll es auch anders sein, gibt es bei meinem Workflow da ein Problem.. welches ihr nicht wissen könnt. Der WF sieht wie folgt aus: Der Initiator (I) des Workflows befüllt ein Formular mit Daten. Unter anderem mit einem Abteilungs-Merkmal (AM) Über SQL greife ich auf Basis des AM auf eine „Routing Tabelle“ zu. Diese enthält die Informationen, für welche Einheit welche Person (P1) freigabeberechtigt ist. Nun können mehrere Fälle eintreten (nicht alle skizziert): 1. AM Eintrag des I ist richtig und keine Vertretung des P ist aktiv >> P kann freigeben >> OK. 2. AM Eintrag des I ist falsch und keine Vertretung des P1 ist aktiv >> P1 sieht Fehler und korrigiert AM >> Dadurch ist P1 nicht mehr freigabeberechtigt** >> P1 leitet entsprechend Schritt an den nun Freigabeberechtigten (P2) weiter. Angenommen dies führt zu Fall 1 >> OK. 3. Das Problem ist nun im Fall einer aktiven Vertretung. Angenommen der AM Eintrag des I ist richtig und P1 hat eine Vertretung. Dann führt dies beim Check ** zu dem Ergebnis, dass der Vertreter nicht freigabeberechtigt. In anderen Worten, ich habe das Problem zwischen einem berechtigten Vertreter und einem fälschlicherweise bestimmten P1 zu unterscheiden. Aus diesem Grund hatte ich auf ein Merkmal, wie „in_substitution_for“ gehofft um den Check entsprechend zu erweitern. Da das Feld scheinbar erst nach der Freigabe des Schrittes befüllt wird hilft es mir leider nicht. Theoretisch könnte man natürlich die Routing Tabelle um die Vertreter erweitern, was wir allerdings aus verschieden Gründen vermeiden wollen. Weiterhin könnte man P1 dahingehend einschränken, dass das AM nicht korrigierbar ist, sondern im Falle einer falschen Eingabe der Prozess abgebrochen werden muss. Das fühlt sich allerdings auch nicht elegant an. Falls ihr weitere Möglichkeiten seht gerne er damit! :) ** Um dies zu erkennen wird folgendes geprüft: Aktueller User = User laut Routing Table. Falls Nein >> Senden blockieren und Grund User anzeigen; Falls Ja >> Senden erlauben

Hallo zusammen, vielen Dank für eure Antworten! Die Vorschläge sind normalerweise die Lösung zu meinem Problem. Leider, wie soll es auch anders sein, gibt es bei meinem Workflow da ein Problem.. welches ihr nicht wissen könnt. Der WF sieht wie folgt aus: Der Initiator (I) des Workflows befüllt ein Formular mit Daten. Unter anderem mit einem Abteilungs-Merkmal (AM) Über SQL greife ich auf Basis des AM auf eine „Routing Tabelle“ zu. Diese enthält die Informationen, für welche Einheit welche Person (P1) freigabeberechtigt ist. Nun können mehrere Fälle eintreten (nicht alle skizziert): 1. AM Eintrag des I ist richtig und keine Vertretung des P ist aktiv >> P kann freigeben >> OK. 2. AM Eintrag des I ist falsch und keine Vertretung des P1 ist aktiv >> P1 sieht Fehler und korrigiert AM >> Dadurch ist P1 nicht mehr freigabeberechtigt* >> P1 leitet entsprechend Schritt an den nun Freigabeberechtigten (P2) weiter. Angenommen dies führt zu Fall 1 >> OK. 3. Das Problem ist nun im Fall einer aktiven Vertretung. Angenommen der AM Eintrag des I ist richtig und P1 hat eine Vertretung. Dann führt dies beim Check ** zu dem Ergebnis, dass der Vertreter nicht freigabeberechtigt. In anderen Worten, ich habe das Problem zwischen einem berechtigten Vertreter und einem fälschlicherweise bestimmten P1 zu unterscheiden. Aus diesem Grund hatte ich auf ein Merkmal, wie „in_substitution_for“ gehofft um den Check entsprechend zu erweitern. Da das Feld scheinbar erst nach der Freigabe des Schrittes befüllt wird hilft es mir leider nicht. Theoretisch könnte man natürlich die Routing Tabelle um die Vertreter erweitern, was wir allerdings aus verschieden Gründen vermeiden wollen. Weiterhin könnte man P1 dahingehend einschränken, dass das AM nicht korrigierbar ist, sondern im Falle einer falschen Eingabe der Prozess abgebrochen werden muss. Das fühlt sich allerdings auch nicht elegant an. Falls ihr weitere Möglichkeiten seht gerne er damit! :) ** Um dies zu erkennen wird folgendes geprüft: Aktueller User = User laut Routing Table. Falls Nein >> Senden blockieren und Grund User anzeigen; Falls Ja >> Senden erlauben

Hallo zusammen, vielen Dank für eure Antworten! Die Vorschläge sind normalerweise die Lösung zu meinem Problem. Leider, wie soll es auch anders sein, gibt es bei meinem Workflow da ein Problem.. welches ihr nicht wissen könnt. Der WF sieht wie folgt aus: Der Initiator (I) des Workflows befüllt ein Formular mit Daten. Unter anderem mit einem Abteilungs-Merkmal (AM) Über SQL greife ich auf Basis des AM auf eine „Routing Tabelle“ zu. Diese enthält die Informationen, für welche Einheit welche Person (P1) freigabeberechtigt ist. Nun können mehrere Fälle eintreten (nicht alle skizziert): 1. AM Eintrag des I ist richtig und keine Vertretung des P ist aktiv >> P kann freigeben >> OK. 2. AM Eintrag des I ist falsch und keine Vertretung des P1 ist aktiv >> P1 sieht Fehler und korrigiert AM >> Dadurch ist P1 nicht mehr freigabeberechtigt* >> P1 leitet entsprechend Schritt an den nun Freigabeberechtigten (P2) weiter. Angenommen dies führt zu Fall 1 >> OK. 3. Das Problem ist nun im Fall einer aktiven Vertretung. Angenommen der AM Eintrag des I ist richtig und P1 hat eine Vertretung. Dann führt dies beim Check * zu dem Ergebnis, dass der Vertreter nicht freigabeberechtigt. In anderen Worten, ich habe das Problem zwischen einem berechtigten Vertreter und einem fälschlicherweise bestimmten P1 zu unterscheiden. Aus diesem Grund hatte ich auf ein Merkmal, wie „in_substitution_for“ gehofft um den Check entsprechend zu erweitern. Da das Feld scheinbar erst nach der Freigabe des Schrittes befüllt wird hilft es mir leider nicht. Theoretisch könnte man natürlich die Routing Tabelle um die Vertreter erweitern, was wir allerdings aus verschieden Gründen vermeiden wollen. Weiterhin könnte man P1 dahingehend einschränken, dass das AM nicht korrigierbar ist, sondern im Falle einer falschen Eingabe der Prozess abgebrochen werden muss. Das fühlt sich allerdings auch nicht elegant an. Falls ihr weitere Möglichkeiten seht gerne er damit! :) * Um dies zu erkennen wird folgendes geprüft: Aktueller User = User laut Routing Table. Falls Nein >> Senden blockieren und Grund User anzeigen; Falls Ja >> Senden erlauben