So… what? Any previous node with output, even if that output is way back at the start of the workflow is then returned to the parent workflow, ignoring any final output from a final node on the child workflow? That seems a bit “silly”.
In the sub-workflow screenshot, the Merge node needs two inputs. Otherwise it stops the flow execution at this point in production.
Also you do need a fallback branch in Switch.
Could you post both workflows or at least subWF using the </> button?
I’m not sure I can really post the JSON of the workflows as there’s over 150 nodes on each workflow.
You’ve said the execution stops at the merge node because it needs two inputs… but you can see that it continues execution until the final node, so I’m not sure what you mean.
You’ve said I need a fallback brand in switch. Well, I’m not that I actually need one, but when I do have a fallback on ANY switch earlier in the workflow, the parent workflow receives that output (from the fallback) and not the output from the final node which is why I tried turning off the fallback but the result was that the parent workflow only received a NULL output from the child workflow.
At least some meaningful fragments of both, with some pinned data. It is much easier to look into interactive workflows as well as copy them to the canvas to test thing and propose edits (as interactive postings as well) than reproducing whatever from screenshots.
Please help to help you.
but you can see that it continues execution until the final node, so I’m not sure what you mean.
What do you see in wf execution tab on terms of execution sequence and data passing through?
but when I do have a fallback on ANY switch earlier in the workflow, the parent workflow receives that output (from the fallback)
This is possible if neither condition matches and fallback is not connected to anything past it.
Again, hard to tell without possibility to put the hands on it. You have all the context and data. We here can only try to guess based on the bits of information you provide past your interpretation. It may take a ton of back and forth work to try figure it out this way.
Well I can’t give part of a workflow. I guess I’d have to create a “proof of issue” workflow.
That last node perfectly outputs the data I want… but the earlier switch nodes with output going out the fallback output is all the parent workflow seems to care about.
