Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Principle:Langgenius Dify Workflow Application Creation

From Leeroopedia
Knowledge Sources Dify
Domains Workflow, DAG, Frontend
Last Updated 2026-02-12 00:00 GMT

Overview

Description

Workflow Application Creation is the foundational principle governing how DAG-based workflow applications are instantiated in the Dify platform. In Dify, every application is created through a unified createApp API call, but the application's runtime behavior is entirely determined by the mode parameter. To produce a workflow application -- one that executes as a directed acyclic graph (DAG) of nodes rather than a simple prompt-response interaction -- the caller must specify one of two workflow-capable modes: workflow or advanced-chat.

The workflow mode creates a pure DAG pipeline: the user provides inputs, the graph executes node-by-node from the Start node to the End node, and the final output is returned. There is no conversational memory or multi-turn interaction. This mode is suited for batch processing, document transformation, and automated pipelines.

The advanced-chat mode creates a conversational workflow: the DAG graph still governs execution, but the application maintains conversation context across turns and uses an Answer node (instead of an End node) to stream responses back to the user. This mode is suited for chatbot-style applications that require complex multi-step logic.

Usage

When creating a new workflow application in the Dify frontend:

  • Set mode to AppModeEnum.WORKFLOW (value: 'workflow') for non-conversational DAG pipelines.
  • Set mode to AppModeEnum.ADVANCED_CHAT (value: 'advanced-chat') for conversational DAG workflows.
  • The remaining parameters (name, icon_type, icon, icon_background, description, config) are shared across all application types.
  • Upon successful creation, the backend returns an AppDetailResponse containing the new application's ID, which is then used for all subsequent workflow graph operations.

Theoretical Basis

The principle draws from two established patterns:

  • Factory Pattern with Discriminator: A single creation endpoint handles multiple product types, with a discriminator field (here, mode) selecting the concrete behavior. This avoids API surface proliferation while maintaining clean separation of runtime behaviors.
  • DAG Execution Model: Workflow applications adopt the directed acyclic graph paradigm commonly used in pipeline orchestration systems (e.g., Apache Airflow, Prefect). Each node in the graph represents a discrete processing step, and edges represent data flow dependencies. The distinction between workflow and advanced-chat maps to the difference between batch DAG execution (single pass, no state) and stateful DAG execution (multi-turn, with conversation memory).

The AppModeEnum enumeration ensures compile-time safety by restricting possible modes to exactly five values: completion, workflow, chat, advanced-chat, and agent-chat. Only the latter two of the workflow-capable modes produce applications with a visual DAG builder.

Related Pages

Page Connections

Double-click a node to navigate. Hold to expand connections.
Principle
Implementation
Heuristic
Environment