Sub-Workflow: new Input/Output nodes

Feature Requests
,
1

From a previous technology, there is the ability to explicitly select which data stream will be output from the Sub-workflow, and also the ability to have multiple input/output data streams for the Sub-Workflow. Essentially there would just be two new nodes created for Sub-Workflows a “Input” and “Output” node,

Some nuances to this;

  • You can add multiple of either node which would then be reflected back on the “Execute Sub-workflow” node to where it would have the added inputs/outputs for connectors
  • You could label the connections points (Similar to the “Switch” node)
  • You can have one input be “Run for each item” but then every other input would have to be “Run with all items” (I think this may be necessary to prevent cartesian join type operations)

Some reasons for this is;

  • The current logic that determines what data is output from the sub-workflow seems un-intuitive (like is it the furthest right node, or the lowest node, or the last built node, or last in the branch).
  • If I have a sub-workflow that has multiple branches that end then it seems like I have to do a unnecessary merge (merge branches but only take branch #1) to ensure the data I want to output is correct (I face this when a sub-workflow has 3 branches say one that sends an email/alert, one that logs to a database, and and one that streams data back to the parent workflow)
  • The multiple inputs/outputs has so many uses; like feeding in a datastream that was created in the parent workflow (so now it is like a temp table) and then having the sub-workflow run for each item while also needing to use that datastream, Having multiple outputs helps if you have multiple branches created in the sub-workflow to output back to the parent workflow.
2

Voted. The labeled connection points idea is particularly useful - right now when a sub-workflow has multiple branches, deciding which one becomes the output requires an extra Merge node just to consolidate, which adds unnecessary overhead. Explicit Input/Output nodes would also make sub-workflows much easier to read when shared as templates, since the data flow intent would be visible from the canvas without needing to dig into configuration.