The outcome
Publish a reviewable workflow that uses LLM judgment only where needed and keeps business rules deterministic.
Dify is a open-source low-code platform for AI applications, workflows, agents, knowledge, and LLM operations. Building low-code AI workflows, chatflows, agents, RAG applications, model integrations, plugins, and deployable APIs with operational visibility. This guide narrows that broad capability into one repeatable outcome, with checkpoints that keep the source material and your judgment in the loop.
Before you begin
Set the boundary before the tool starts.
Choose one real task, identify who will use the result, and decide what evidence or test will make the result acceptable. Gather only the source material needed for that task. If the work contains confidential, personal, regulated, or client-owned information, confirm that the platform and account are approved before sharing it.
AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.
Step by step
A workflow you can repeat.
- 01
Define the user, input schema, data classification, desired output, model budget, deterministic rules, approval points, and failure states.
- 02
Create a blank Workflow with validated User Input fields and clearly named variables, then add IF/ELSE branches for rule-based decisions.
- 03
Add the minimum LLM and tool nodes with constrained prompts, structured outputs, least-privilege credentials, timeouts, and safe error routes.
- 04
Use templates for fixed formatting and test individual nodes plus full runs with normal, malformed, adversarial, provider-failure, and cost cases.
- 05
Publish a version only after review, run a live smoke test, monitor node logs and token use, and retain an export and rollback procedure.
Working standard
What good use looks like.
- Keep deterministic rules outside LLM nodes.
- Use typed variables and structured outputs.
- Test every failure branch.
Dify workflows can connect models, knowledge, code, plugins, webhooks, and external tools that carry different data and execution risks. Isolate workspaces, protect provider and app keys, prefer deterministic nodes for fixed rules, validate every input and output, treat plugins as code, restrict tools and knowledge access, inspect logs and retention, test failure and pause paths, pin self-hosted versions, and keep exports and rollback procedures.
Official references
Check the current product documentation.
Features, plan limits, availability, and data controls change. These official pages are the starting points used for this collection.