Execute Workflow node. Success branch not firing downstream despite emitting data; or both branches firing simultaneously with Always Output Data enabled

Help me Build my Workflow
,
1

Hi all - running into a stubborn issue with the Execute Workflow node’s dual-output behavior when “On Error: Continue (using error output)” is set. Hoping someone has hit this and found a clean pattern.

Setup

  • A parent workflow calls a sub-workflow via Execute Workflow.

  • Execute Workflow node settings:

    • Mode: Run once for each item

    • Wait for Sub-Workflow Completion: ON

    • On Error: Continue (using error output)

  • The sub-workflow’s terminal node is a Google Sheets update.

  • Parent has two downstream branches: success path (cleanup + Telegram alert + form completion page) and error path (Telegram error alert + error completion page).

The behavior I’m seeing

I have two failure modes depending on the Always Output Data setting on the parent’s Execute Workflow node:

Case A - Always Output Data OFF on the parent’s Execute Workflow node:

  • On sub-workflow success: terminal node (Sheets update) emits 1 item with full row data. The parent’s Execute Workflow node Success Branch tab clearly shows the item present. But downstream nodes wired to the success port don’t fire. The execution just stops at Execute Workflow with no error and no further routing.

  • On sub-workflow error: the error branch fires correctly with the error payload. Clean.

Case B - Always Output Data ON on the parent’s Execute Workflow node:

  • On sub-workflow success: both success and error branches fire (success with the real data, but also a phantom run somehow).

  • On sub-workflow error: both branches fire simultaneously: success branch fires with an empty placeholder item {}, error branch fires with the actual error payload. Both downstream paths execute in parallel, which causes duplicate Telegram alerts and conflicting form completion pages.

What I’ve tried

  1. Toggling Always Output Data on the sub-workflow’s terminal Sheets node ON, with the parent’s Execute Workflow Always Output Data OFF. Sub-workflow’s terminal node confirms it emits 1 item with full data when checked in the sub-execution log. Parent Execute Workflow’s Success Branch tab also shows that item. Downstream nodes still don’t fire.

  2. Verified Wait for Sub-Workflow Completion is ON.

  3. Verified wiring on the canvas - success port to cleanup node, error port to alert node. No accidental swaps.

  4. Tried both “Run once for each item” and “Run once with all items” modes. Same result.

  5. Re-drew the connector lines from the success port. No change.

What I want

The standard dual-output pattern most people seem to use:

  • Sub-workflow succeeds → only the success branch fires downstream → cleanup + success alert run.

  • Sub-workflow throws → only the error branch fires downstream → error alert + recovery UI run.

  • Never both at once.

Questions

  1. Is Continue (using error output) known to misbehave when the sub-workflow’s terminal node returns items but the parent’s Execute Workflow port doesn’t propagate to downstream nodes? Is there a specific n8n Cloud version where this is patched?

  2. Is there a canonical pattern people use to get clean dual-routing - maybe with a Merge node, an IF check on $json.error, or some structural workaround I’m missing?

Any pointers appreciated. Happy to share more details of what else would be needed (as JSON code, workflow screenshots and other).

Thanks.

1 Like
2

Welcome @Nick_Vieru to our community! I’m Jay and I am a n8n verified creator.

The dual-branch behavior with “Always Output Data” ON is a known quirk - keep that OFF. The cleaner pattern: leave “On Error: Continue (using error output)” as is, and add an IF node immediately after the Execute Workflow node checking {{ $json.error !== undefined }}. Success outputs from the sub-workflow won’t carry an error object; error outputs will. That gives you clean explicit branching without the phantom run issue.

One thing worth reviewing: make sure your sub-workflow’s terminal node isn’t accidentally swallowing the error before it reaches the parent - if the sub-workflow has its own error handler that catches and transforms the error into a normal output, the parent Execute Workflow node won’t see it as an error.

3

@Nick_Vieru
Please share your JSON.

4

Hey Jay, Thanks a lot for the brief response!

Will try what you suggested and tell you if it fixed the issue!

1 Like
6

Thanks Jay, it worked! Had to make some adjustment in the workflow that is being executed within the workflow I had issues. Basically, there were 2 more nodes that were at the terminal position, and it was never reaching them as they had a conditional as well, and for the scenario I was running, that conditional never fired. Therefore, the terminal node was never reached and the execute workflow success branch could never fire as it never heard back from the workflow it executed that it successfully finished.

Put the IF conditional inside the workflow with the issue and added a branch of the IF conditional node to a (in the workflow that was called upon/executed within) to no operation one, and it works!

1 Like
7

Glad it worked out! Moving the IF conditional inside the sub-workflow is actually a cleaner pattern anyway - it keeps the branching logic self-contained so the parent doesn’t need to know about the internal structure of what it’s calling.

2 Likes
8

Already fixed, thanks!

9

You’re very welcome! If everything’s working as expected now, feel free to mark the relevant reply as the solution, and have an awesome day ahead!

1 Like
10

Heyo, I’m new to the forum. How can I do that?

1 Like
11

Oh, my bad – I just realized this topic is in the “Help me Build my Workflow” category, not “Questions”.
The “Mark as solution” feature is only available in the “Questions” category, so that’s why you’re not seeing the option here.
Thanks a lot for being willing to mark a solution though, I really appreciate it! Unfortunately this category just doesn’t support that feature.