Today, we are introducing the new Dify Trigger capability.
Previously, a Dify Workflow could only be started in two ways, either by a user manually running it in the UI or by an external system calling it via API. Each call kicked off a single run and then stopped.
With Trigger, a Workflow can behave more like a background service that continuously listens for events. The moment a condition is met, it automatically starts running with the right context.
Why Trigger Matters
Once you scale automation beyond a handful of flows, the biggest pain point often is not the logic itself but how each flow gets started.
With only a few Workflows, teams can simply agree on who runs what and when. But as more Workflows get added, trigger logic naturally fragments. Some flows are tied to UI buttons, some depend on cron scripts, and others are called directly from business systems.
As soon as triggers are scattered, operational overhead explodes. It becomes hard to answer which flows fire when specific events happen, debugging becomes painful because you do not know where to start looking, and dead or forgotten entry points quietly accumulate.
At the core, this is a split between the trigger and the execution. The job of Trigger is to bring the decision of when to start back into the orchestration layer and make event listening a native capability of Dify Workflow.
Whether the event is time‑based, a SaaS status change, or a business callback, you can define it, filter it, and route it on the same canvas before handing off to downstream LLMs, Agents, and tool nodes for actual processing.
Where Trigger Fits Inside a Workflow
With Trigger, a Workflow now has two primary ways to start.
User input. This starts when a user or API provides input parameters and runs once per call. It is ideal for tools, interactive assistants, or on‑demand utilities.
Trigger. This continuously listens to an event source. When conditions are met, it converts the event payload into structured variables and passes them into the Workflow. You can configure multiple Triggers on the same canvas, driving different branches and later merging them if needed.
Three Trigger Types in Dify v1.10.0
In Dify v1.10.0, Trigger comes in three forms that cover the most common event sources, including scheduled tasks, third‑party platforms, and internal systems.
1. Schedule Trigger: Time‑Based Automation
Schedule Trigger starts a Workflow on a fixed schedule. It is ideal for daily reports, recurring data cleanup, regular health checks, and any other predictable, time‑driven jobs.
You can configure it hourly, daily, weekly, or monthly, or use a cron expression for finer control.
When it fires, it provides useful variables like timestamps that downstream nodes can use to query data, generate reports, send notifications, and more.
2. Plugin Trigger: Events From Third‑Party Apps
Plugin Trigger starts a Workflow when something happens in a third‑party application. It uses Dify plugins that subscribe to external events. Typical use cases include new or updated Pull Requests in a code repo, new tickets in a helpdesk system, or document updates in collaboration platforms.
For popular SaaS tools, we provide ready‑to‑use Trigger plugins.
In Dify, Trigger‑type plugins work by exposing a list of subscribable events after you install and authorize the plugin. In your Workflow, you simply add a Plugin Trigger and select the events you care about. When the external app sends an event to the subscription endpoint, the Workflow automatically starts and receives a clean, structured payload parsed by the plugin. The same subscription can fan out to multiple Workflows without the need to configure it repeatedly.
3. Webhook Trigger: Connect Your Own Systems
Webhook Trigger is designed for custom systems or services that do not yet have a plugin.
For each Webhook Trigger, Dify generates a unique HTTP URL. Whenever your business system calls that URL, it starts the Workflow. Request query params, headers, and body are passed into the Workflow as variables and can be used directly by downstream nodes. If needed, the Webhook can return the result of the Workflow, along with status or error information, back to the caller. This makes it straightforward to wire Dify into existing backends, internal tools, or legacy systems.
What You Can Build With Trigger
With Trigger, Dify Workflows can handle full, end‑to‑end business processes rather than just isolated tasks.
On a single canvas, you can combine multiple Triggers, condition branches, LLM analysis, Agent reasoning, loops, HTTP calls, knowledge base retrieval, and more to build truly event‑driven automation systems.
Quick Example: GitHub PR Review Assistant
As a concrete example, here is how to build a three‑node Workflow that listens for new Pull Requests in GitHub, analyzes the changes, and pushes review highlights to a Slack channel.
Step 1: Configure the Plugin Trigger
In your Workflow canvas, click Add node and choose Start. Select the GitHub Trigger plugin and pick the Pull Request (Unified) event, then authorize and choose the repository you want to monitor.
This Trigger listens for key PR lifecycle events, such as when a PR is opened, updated, closed, or merged.
On the right‑hand configuration panel, you can fine‑tune which PRs should trigger the Workflow. For example, you can filter by event type such as opened or synchronize, target branch, author, draft or non draft status, PR size, and so on.
A typical setup might listen to all non‑draft PRs targeting the main branch of a specific repository and trigger whenever someone creates, updates, pushes commits to, or closes such a PR.
Step 2: Add LLM Analysis
Next, add an LLM node. In the prompt, instruct the model to use the four output variables from the Trigger, which are action, pull_request, repository, and sender.
The model can then understand what happened in this PR, extract key fields like title and description, summarize the changes, and highlight risks or areas needing attention. The output should be a concise set of review notes or a short summary the reviewer can act on.
Step 3: Push Results to Slack
Finally, add a Slack node. Paste your Slack Incoming Webhook URL and set the message content to the LLM node output.
Now, whenever a qualifying PR event occurs, the Workflow runs end‑to‑end and posts a review summary to the designated Slack channel, typically within seconds.
The Slack message can include a quick overview of the event, a summary of key changes, important details like the branch and author, and suggested next steps. Reviewers can quickly understand the impact and priority of the PR without even opening GitHub.
What Is Next
Trigger upgrades Dify Workflow from merely running when called to running whenever events happen. Your automations can now proactively sense and respond to changes in your environment, making business events the true center of your system.
Next, we will continue expanding supported event types and the plugin ecosystem. We will also introduce human‑in‑the‑loop capabilities so Workflows can pause at critical steps, wait for human approval, and then resume execution.
If you are already using Dify for AI‑powered automation, Trigger is a natural next step. Start with a simple scenario, move your scattered triggering logic into the Workflow canvas, and let events drive your automation.
You can find more details in the documentation.
