Aktuell ist nichts anderes geplant. Der FlowExecutingStep und FlowTrigger sind die beiden Möglichkeiten. Wiederverwendbare Logik sollte wie von Stefan vorgeschlagen in einen separaten Flow ausgelagert werden, der dann aufgerufen wird. Mittlerweile gibt es beim FlowExecuting Step eine Erweiterung, die die Arbeit damit vereinfacht. Und zwar kann man jetzt aus dem Aufrufer (A) direkt in den aufzurufenden Flow (B) in eine sog. Sub-Flow-Ansicht springen. Dabei werden die Flow-Variablen mit den Daten des Aufrufers befüllt. Das erleichtert das Entwickeln mit diesem Konstrukt um einiges.


Die von Tobias angesprochene Lösung ist nur eine interne Notlösung gewesen, deren Entfernung nur noch eine Frage der Zeit ist.
Hallo Diana,
wir müssen als Plattformbetreiber darauf achten, dass Prozesse schlank und schnell abgearbeitet werden. Schon heute ist es ein Problem, dass Flows zu viele Steps haben und damit zu komplex werden. Das macht Flows fehleranfällig, schwer intern zu optimieren, schwer zu debuggen, schwer zu verstehen usw..
Wir halten daher die Skip-Logik für sehr schädlich und werden diese nicht umsetzen. Synesty ist an einigen Stellen schon komplex genug.
Evtl. finden wir irgendwann in Zukunft dafür einen anderen Lösungsansatz. Da die Thematik aber sehr tief in der Plattform liegt, ist das sehr komplex und hat Auswirkungen auf alle Bereiche, insbesondere User-Interface, Abarbeitungslogik, Performace etc. . D.h. hier ist nicht mit einer Schnellschuss-Lösung zu rechnen.
Vielleicht können wir dir einen anderen Tip geben, wie du deinen Flow bauen kannst und trotzdem zum Ziel kommst.
Da wäre ein konkreteres Beispiel hilfreich.
Haben gerade noch mal im Team nachgefragt:
Aussage war:
Klingt nach FlowExecuting Step (mit Condition).
Meistens ist es machbar einen zusätzlichen Flow zu erstellen, der für alle Lager ausgeführt werden kann und die LagerID als Flow-Variable zu übergeben:
FlowA:
1.Download Datei
2. Filter Lager 1
3. -> FlowExecuting Step ruft FlowB auf (mit weitere Verarbeitung, Status in Plenty setzen )
4. Filter Lager2
5 -> FlowExecuting Step ruft FlowB auf (mit weitere Verarbeitung, Status in Plenty setzen )
5. Filter Lager 3
6. -> FlowExecuting Step ruft FlowB auf (mit weitere Verarbeitung, Status in Plenty setzen )
Flow B (wird von FlowA mehrmals mit unterschiedlichen Parametern aufgerufen):
weitere Verarbeitung, Status in Plenty setzen
Alternative 1 FlowTrigger:
Auch mit dem FlowTrigger ließe sich das realisieren (ab Starter verfügbar). Da kann man nur keine Spreadsheets übergeben sondern würde nur die LagerID an FlowB übergeben. Dort muss dann auch der Abruf der Daten erfolgen.