Wait node vs Human in the loop node

[shakthipsg]

Describe the problem/error/question

We have a use-case where we trigger sub-workflow with Split-out. We want ‘N’ sub-workflows to be triggered in-parallel where ‘N’ is the number or items that we split-out, we are using ‘Webhook trigger’ to trigger sub-workflows with ‘Respond: When last node finishes’. All the sub-workflows are triggered in-parallel.
When we have a ‘Wait’ node in the sub-worklow, main workflow waits for all sub-workflows to complete. But when we have ‘Human in the loop’ node, main workflow resumes once the sub-workflow moves to wait on ‘Human in the loop’ node.
Is this expected with ‘Human in the loop’ node?

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

• n8n version:
• Database (default: SQLite):
• n8n EXECUTIONS_PROCESS setting (default: own, main):
• Running n8n via (Docker, npm, n8n cloud, desktop app):
• Operating system:

[tamy.santos]

Hi @shakthipsg

Yeah, this behavior is expected given current n8n limitations, but I totally agree it’s not intuitive.

Here’s what’s happening:

Any sub-workflow that contains a node which waits (Wait node, Webhook/Wait, Human-in-the-loop, etc.) has special behavior when called from another workflow. In n8n v1.x this is a known limitation — when a sub-workflow goes into a waiting state, the parent workflow doesn’t correctly “stay blocked” and/or receive the final output once the sub-workflow resumes.

Specifically for Human-in-the-loop in a sub-workflow: support has confirmed that “anytime you use a wait node in a sub-workflow it will not output data back to the main one” and that this won’t be fully fixed until a major update (n8n 2.0).

So in your case:

With a Wait node in the sub-workflow, you’re seeing the parent effectively wait until the sub-workflow finishes (which is what you want).

With a Human-in-the-loop node in the sub-workflow, the parent resumes as soon as the sub-workflow enters the waiting state. That matches the current limitation — sub-workflows that go into a “wait” state (including HITL) don’t behave like a true “block until done” from the parent’s perspective.

Unfortunately, there’s no configuration switch to make Human-in-the-loop behave like your Wait node in this pattern. Current workarounds are:

• Keep the Human-in-the-loop logic in the main workflow (not in a sub-workflow), or
• Use a Wait node with “On Webhook Call” and build your own human-in-the-loop UI/logic around that, which is the recommended generic pattern.

Reference:

15 best practices for deploying AI agents in production

How to do a human-in-the-loop workflow without a human-in-the-loop node

Describe the problem/error/question I put in a feature request to add a RocketChat man-in-the-loop node, so far not much interest. How can I create workflow that does the same thing to use in the meantime? I have a developer background, just new to n8n. Looking for some general guidance, maybe: “here’s a video/url that shows you”, or just use such and such node along with such and such node … need to implement this api which rocketchat is missing and that’s why we don’t have a man-in-the-midd…

Sub workflow with Human in the Loop does not return an output

Describe the problem/error/question I have a main workflow and a sub workflow. I have a “Human in the loop” node in a sub-workflow. The issue is that I can’t get an output value from the sub-workflow in the main workflow. I always get a value of the previous node (just before the sub-workflow execution). If I remve “Human in the loop” - everything works fine. What is the error message (if any)? No errors, just no output. Please share your workflow Main workflow Sub w…

[Anshul_Namdev]

Hi @shakthipsg This is an expected behavior of the HITL node as wait node is just supposed to wait for a certain amount and when using HITL nodes they behave and hold it down until the human handles the requested intervention, HITL nodes are better as they give information while holding the workflow not just hold the workflow for a certain amount of time, hope this helps and please report AI generated replies! Cheers!

[shakthipsg]

@tamy.santos

@tamy.santos

With a Wait node in the sub-workflow, you’re seeing the parent effectively wait until the sub-workflow finishes (which is what you want).

This works for us. But want to understand that whether this is the expected case, or just working for minimal wait time interval.

[tamy.santos]

@shakthipsg

Unfortunately, it’s not a stable or supported behavior, and it can break as soon as the wait becomes longer or involves real human interaction. This limitation is known and expected until a major architectural change is implemented.