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

ساعدني في بناء سير عملي
,
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)
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)
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)
7

سعيد بأن الأمر نجح! نقل شرط IF إلى داخل سير العمل الفرعي هو في الواقع نمط أنظف - فهو يحافظ على منطق التفرع مستقلاً بذاته بحيث لا تحتاج العملية الأب إلى معرفة البنية الداخلية لما تستدعيه.

إعجابَين (2)
8

تم إصلاحه بالفعل، شكراً!

9

أهلاً وسهلاً! إذا كان كل شيء يعمل كما هو متوقع الآن، فلا تتردد في وضع علامة على الرد ذي الصلة باعتباره الحل، وتمتع بيوم رائع!

إعجاب واحد (1)
10

مرحبا، أنا جديد في المنتدى. كيف يمكنني فعل ذلك؟

إعجاب واحد (1)
11

آه، آسف على ذلك – للتو أدركت أن هذا الموضوع في فئة “ساعدني في بناء سير عملي” وليس في “الأسئلة”.
ميزة “وضع علامة كحل” متاحة فقط في فئة “الأسئلة”، لذلك هذا هو السبب في أنك لا ترى الخيار هنا.
شكراً جزيلاً لأنك مستعد لوضع علامة على الحل، أنا حقاً أقدر ذلك! للأسف هذه الفئة ببساطة لا تدعم هذه الميزة.