A Chatbot has a fixed structure: receive a question, search the knowledge base, generate an answer.
Real requirements are rarely that direct. "First decide whether this is pre-sales or post-sales, then look up the order if it is post-sales, or send the catalog if it is pre-sales" is branching logic a Chatbot cannot do. That calls for a Workflow.
The 30-second overview
| Chatbot | Workflow | |
|---|---|---|
| Structure | Fixed, one question one answer | Open, supports branches and loops |
| Best for | Q&A on a single topic | Multi-step work, classification, external systems |
| Learning curve | Low | Medium |
| Debugging | Check the cited sources | Inspect input and output node by node |
| When to switch | When you catch yourself writing "if... then... otherwise..." in the prompt | |
That last row is the most useful test: the moment you start stuffing conditional logic into a prompt is the signal to move to a Workflow. Models are not good at executing branching logic reliably, so that job belongs to the structure of the flow.
What the common nodes do
Start and End
The Start node defines what input this flow receives. The End node (or Direct Reply) decides what comes back.
Question Classifier
Sorts the user's question into the categories you define, then sends it down different branches. This is the first node in most practical flows.
Classification accuracy depends on how you describe each category. Concrete examples work far better than abstract definitions: "asking about shipping fees, delivery times, or tracking status" beats "logistics-related questions".
Knowledge Retrieval
Pulls relevant passages from a knowledge base you specify. You can attach different knowledge bases to different branches, which is one of the biggest advantages Workflow has over Chatbot.
LLM
Calls a language model. One flow can contain several, each responsible for something different, for example one that summarizes and one that adjusts tone.
Conditional branch
Picks a path based on the value of a variable. The difference from the Question Classifier is this: a conditional branch compares explicit values, while the classifier asks the model to judge meaning. If a conditional branch can solve it, do not reach for the classifier. The former is far more stable and costs nothing in model fees.
HTTP Request
Calls an external API. This is the node that lets a flow look up orders, check stock, or write into another system.
That said, if you have a lot of services to connect and you need retries and error handling, having n8n handle execution is easier to maintain than packing everything into the Workflow.
What a real flow looks like
Using customer support as the example:
- Start — receive the user's question
- Question Classifier — split into "product questions", "order lookup", and "other"
- Product questions → Knowledge Retrieval (product knowledge base) → LLM generates the answer
- Order lookup → HTTP Request (query the order system) → LLM turns the result into plain language
- Other → Direct Reply with a fixed hand-off-to-a-human message
- End
Note step five: do not route every path through the model. A fixed reply only needs a Direct Reply node, which is fast, free, and predictable.
How to debug
Inspect input and output node by node
Debugging a Workflow is a much better experience than debugging a Chatbot, because every node shows you what it received and what it produced. When the result is wrong, work backwards and find the first node whose output does not match what you expected.
Get the flow working first, tune quality second
A common mistake is wiring nodes and tuning prompts at the same time. Connect the whole path with the simplest possible settings first, confirm the data flow is correct, and only then go back and tune the quality of each LLM node.
Use variable names you can read
Nodes pass data through variables. Once a flow gets long, names like `text`, `result`, and `output` will leave you unable to understand your own work three days later.
Variables: the real skeleton of a flow
Nodes pass data to each other through variables. This is the part of Workflow that goes wrong most often and the part fewest people explain clearly.
Every node's output has to be caught
What an LLM node produces, the passages Knowledge Retrieval pulls back, the response from an HTTP Request: all of it is stored as a variable. A later node references it when it needs it.
A common mistake is referencing a variable from a branch that never ran. The flow went down path A but references the output of path B, and the result is empty. Check for this carefully whenever you have multiple branches.
Your naming habits decide whether you understand it three days later
Default names like `text`, `result`, and `output` are tolerable at three nodes and a disaster at ten. Purpose-driven names (`classified_intent`, `order_status`) take almost no extra time, and the debugging time they save is substantial.
A second example: a content moderation flow
Not every Workflow is a conversation. This one handles a batch task:
- Start — receive a piece of user-submitted text
- LLM — decide whether it violates the rules, output "approved" or "needs human review"
- Conditional branch — route based on the previous step's result
- Approved → HTTP Request writes it to the database
- Needs review → HTTP Request notifies an administrator
- End
This example shows two things: a Workflow does not need a human in a conversation, since a system can call it; and letting the model judge while the nodes act is the more reliable division of labor.
When not to use a Workflow
Honestly: if what you need is "answer questions from a document", a Chatbot is enough. Using a Workflow just adds a layer of maintenance.
And if the point of the flow is connecting to a lot of external systems, running on a schedule, and retrying on failure, then the core belongs in an automation tool, with Dify only handling intent understanding. The split is covered in Dify plus n8n.
FAQ
Q: What is the difference between Workflow and Chatflow?
Put simply, Chatflow is a Workflow with conversation memory, which suits multi-turn dialogue, while Workflow is more like one-off task processing. A support bot usually uses Chatflow; batch processing uses Workflow.
Q: How long can one flow be?
There is no real technical limit, but in practice once you pass a dozen or so nodes you should consider splitting it up. Overly long flows are hard to debug, and the failure probability of each node accumulates.
Q: What if the flow runs slowly?
First find out which node is slow. It is usually an LLM node, and that is the model's response time, so adding resources will not help. Consider switching to a faster model, or removing LLM nodes you do not need.
Q: Can a flow run on a schedule?
Dify flows are mainly triggered by requests. If you need scheduling, the common approach is to have an external tool call its API on a timer.
Sources and further links
- Dify official documentation — the complete reference for node types and parameters
- Dify release notes — node features are often added with new versions
Further reading
- Dify Agent guide: letting the AI decide which tool to use
- Dify tutorial: building your first AI chatbot from scratch
- Dify knowledge base guide: chunking, indexing, and retrieval settings
- Dify plus n8n: AI understands, n8n executes
- What Dify is good at: RAG knowledge bases, workflow orchestration, and why it needs more resources
- RoamerHost Dify hosting plans
Want someone to build it for you?
If you would rather not assemble these workflows yourself, or the project is large enough that you want someone planning it with you, Roamer Tech (the company behind RoamerHost) takes on contract work for business process automation and AI agents:
