How to flow to another chatflow?

[tiger822]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

How to realize the flow of the main chatflow to the sub-chatflow (with an interactive interface, which will output tables and charts), and then return to the main chatflow when the sub-chatflow receives the exit?

I don't want to use html jump method, the interface interaction effect is very poor.

[dosubot[bot]]

Dify supports calling a sub-workflow from a main chatflow using the "Workflow as Tool" pattern — you publish a workflow and then invoke it as a tool node within your main chatflow [1]. The sub-workflow executes synchronously and returns its outputs back to the parent flow.

However, there's an important limitation for your use case: sub-chatflows cannot have their own independent interactive interface during nested execution. The pause/human-input mechanism is explicitly disabled for nested workflow calls [2], meaning the sub-flow can't pause to display interactive tables/charts to the user and then wait for an "exit" command before returning.

Possible workarounds:

1. Parent handles all interaction — Have the sub-workflow return its data (table/chart content) to the main chatflow, and let the main chatflow render the output and handle the "exit" logic via conversation variables and conditional branching.

2. Conversation variable routing — Use a conversation variable in a single chatflow to track which "mode" (main vs. sub) the user is in. Route messages through different branches based on that variable, and switch back when the user says "exit."

3. Separate apps with API calls — Run the sub-chatflow as a separate Dify app and invoke it via HTTP Request nodes, though this won't give you a seamless single-interface experience either.

Unfortunately, there's no native "flow to another chatflow with its own interactive UI and return" feature in Dify today. The conversation-variable routing approach within a single chatflow is likely your best bet for a smooth user experience without HTML redirects.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[tiger822]

invoke it as a tool node

I know the function 'invoke it as a tool node'.
I hope to realize that the main flow goes to the sub flow, and after the sub flow interacts with each other, the input exits and then returns to the main flow.

In a typical scenario, the main assistant displays 'Financial Assistant'/'Order Assistant'. When the user selects 'Financial Assistant', the main process goes to the chat flow of the financial assistant, and then the interaction is repeated in the chat flow of the financial assistant until the user inputs and exits, and then returns to the main assistant.

[dosubot[bot]]

Thanks for clarifying — you want true multi-turn interaction within the sub-assistant before returning to the main flow. This isn't natively supported as separate chatflow-to-chatflow handoff, but you can achieve it within a single chatflow using conversation variables and conditional branching:

Pattern:

1. Create a conversation variable, e.g. active_assistant, with a default value of "menu" [1].
2. At the start of your chatflow, add an If/Else node that checks active_assistant:
   • "menu" → route to the main menu branch (presents "Financial Assistant" / "Order Assistant")
   • "financial" → route to the Financial Assistant branch
   • "order" → route to the Order Assistant branch
3. When the user selects "Financial Assistant", use a Variable Assigner node to set active_assistant = "financial" [2]. From the next turn onward, all messages route to the financial branch.
4. In the financial branch, check if the user input is an exit command (e.g., "exit" or "back"). If yes, use Variable Assigner to reset active_assistant = "menu". Otherwise, process normally with the financial LLM/knowledge base.
5. The conversation variable persists across turns automatically [3], so the user stays in the financial assistant until they explicitly exit.

This gives you the multi-turn sub-assistant interaction you want — the user stays "inside" the Financial Assistant for as many turns as needed, and returns to the main menu on exit — all within one chatflow. Each sub-branch can have its own LLM node, knowledge base, and output formatting (tables, charts, etc.).

The downside is that it's a single chatflow that gets more complex as you add more assistants, but it's currently the most effective way to achieve this behavior in Dify without relying on HTML redirects or external orchestration.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[tiger822]

Thanks for clarifying — you want true multi-turn interaction within the sub-assistant before returning to the main flow. This isn't natively supported as separate chatflow-to-chatflow handoff, but you can achieve it within a single chatflow using conversation variables and conditional branching:

Pattern:

1. Create a conversation variable, e.g. `active_assistant`, with a default value of `"menu"` [[1]](https://github.com/langgenius/dify/blob/e26214c02dd3aaf9fdf2c97230f2f5bbefc70526/api/core/app/apps/advanced_chat/app_runner.py#L399-L416).

2. At the start of your chatflow, add an **If/Else node** that checks `active_assistant`:
   
   * `"menu"` → route to the main menu branch (presents "Financial Assistant" / "Order Assistant")
   * `"financial"` → route to the Financial Assistant branch
   * `"order"` → route to the Order Assistant branch

3. When the user selects "Financial Assistant", use a **Variable Assigner** node to set `active_assistant = "financial"` [[2]](https://github.com/langgenius/dify/blob/e26214c02dd3aaf9fdf2c97230f2f5bbefc70526/api/services/workflow_draft_variable_service.py#L919-L939). From the next turn onward, all messages route to the financial branch.

4. In the financial branch, check if the user input is an exit command (e.g., "exit" or "back"). If yes, use Variable Assigner to reset `active_assistant = "menu"`. Otherwise, process normally with the financial LLM/knowledge base.

5. The conversation variable persists across turns automatically [[3]](https://github.com/langgenius/dify/blob/e26214c02dd3aaf9fdf2c97230f2f5bbefc70526/api/core/app/layers/conversation_variable_persist_layer.py#L22-L48), so the user stays in the financial assistant until they explicitly exit.

This gives you the multi-turn sub-assistant interaction you want — the user stays "inside" the Financial Assistant for as many turns as needed, and returns to the main menu on exit — all within one chatflow. Each sub-branch can have its own LLM node, knowledge base, and output formatting (tables, charts, etc.).

The downside is that it's a single chatflow that gets more complex as you add more assistants, but it's currently the most effective way to achieve this behavior in Dify without relying on HTML redirects or external orchestration.

To reply, just mention @dosu.

Docs are dead. Just use Dosu.

yes, this all-in-one working mode is very unfavorable for complex business needs.
I hope that the new version can realize the menu-routing requirement similar to the front-end app I mentioned. I believe that most developers with real project needs have this requirement.