How a Dify Slack integration starts workflows from channel events
A team that wants a Slack message or channel event to start a Dify workflow and get a reply in the same channel should use the langgenius Slack trigger plugin from the Dify Marketplace, which receives workspace events. A self-hosted instance also has to expose an address that Slack can reach, because the trigger depends on that inbound path to receive events at all. The Marketplace listing at Dify Marketplace: Slack trigger is the starting point for confirming which events are supported and which setup fields the plugin asks for.
The work divides into three parts. The trigger only receives events and passes their payload into the workflow. The workflow decides what happens: it can read the message text, check the channel or user, call a model or knowledge base, and branch on conditions. Tool plugins perform the outbound actions, such as posting the answer back to the channel. Keeping these roles separate makes it easier to test each part alone and to see which component failed when a reply does not arrive. Before building, confirm the exact trigger input fields, the reply tool's parameters and the Slack app scopes and event subscriptions in the plugin listing and Slack's own console, since these details can change between plugin versions and are not fixed by this page.
Two environment decisions shape the build. The TRIGGER_URL variable must be set to the address that upstream services call, so a wrong value means Slack delivers events to a URL the instance cannot correctly answer. Confirm with your network team whether that address is reachable from Slack's servers, and whether it sits behind a load balancer, reverse proxy or firewall rule that must allow inbound requests. Also decide how far the trigger's scope reaches: limit which channels and workflows respond, and plan who can edit the workflow that posts replies, because anyone who can change it can change what the bot says and which tools it uses.
What a self-hosted Dify needs before Slack events can arrive
A Slack trigger only works when Slack can reach a Dify instance at an address you control, and when that instance can call back out to Slack. The cards below cover the Dify side, the Slack app settings, the public trigger address and the outbound path, plus who owns each piece before the build starts.
Dify version and edition
Confirm the Dify version you will run and its edition before choosing a trigger design. The Docker Compose docs set minimums of 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later, and the Compose stack includes the api, worker, web and plugin daemon services, plus PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. Plugins such as the Slack trigger depend on the plugin daemon, so check that your target version supports the plugin version you plan to install.
Slack app rights to install
Installing and subscribing a Slack trigger requires a Slack app with the scopes and event subscriptions the plugin asks for, and a Slack workspace admin who can approve that app. Ask the Slack owner to confirm whether your workspace requires admin approval for new apps, which events the trigger needs, and whether the app is installed in a single workspace or distributed further. Record who holds the app credentials.
Event subscription and request verification
Slack sends event payloads to an HTTPS endpoint you register and expects a challenge response when you set it up. Confirm which event types the Slack trigger subscribes to, and decide who can change the subscription. Slack signs requests with a signing secret, so store that secret in your secrets manager and confirm the plugin verifies signatures before any workflow runs.
Public trigger address
A self-hosted Dify must expose a public address that upstream services call, which the environment reference names through TRIGGER_URL. This value has to match the hostname Slack reaches, not the internal address Nginx listens on behind a reverse proxy. Set it before registering the subscription, and plan a change window if the hostname later moves.
TLS and DNS ownership
Slack only delivers events to HTTPS endpoints, so the trigger hostname needs a DNS record and a certificate that browsers and Slack's servers trust. Name the team that owns the DNS zone, the certificate issuer and the renewal process. Check whether your internal policy allows the trigger hostname to be reachable from the public internet, and confirm how Nginx terminates TLS in your layout.
Outbound path from Dify to Slack
Dify must reach Slack's API to post replies through tool plugins. Outbound requests from Dify pass through the SSRF proxy, which blocks internal and private IP ranges, so confirm that the Slack API hosts are reachable through that proxy and that your egress firewall permits them. Ask your network team to test this from the Dify host, not from a workstation.
Configuring the Slack trigger and reply path in Dify
This sequence connects a self-hosted Dify instance to a Slack app so that a channel event starts a workflow and the result returns to the same channel, tested in one channel before wider use.
Set the trigger address in the environment file
The operator sets TRIGGER_URL in the Dify environment file to the public address that Slack will call, then restarts the services so the value takes effect. TRIGGER_URL is one of Dify's common URL variables and must be the address upstream services call, so it has to resolve from the internet and reach the instance over HTTPS through your reverse proxy. Confirm the exact variable behavior in the environment variable reference before you change it. The step is done when the console loads over the same host name and the value is visible in the running configuration.
Install the Slack trigger plugin
A workspace administrator installs the langgenius Slack trigger plugin from the Dify Marketplace into the workspace that will own the workflow. Check the plugin listing for the version, the supported event types and any setup notes, and record them with the change. Plugin installation is performed in the console by a person with the right role, and the plugin should come from the official publisher listed on the Marketplace. The step is done when the plugin appears in the workspace plugin list with no install errors in the plugin daemon logs.
Create or confirm the Slack app and event subscription
In Slack's app administration screens, the Slack owner creates a new app or opens an existing one, then enables event subscriptions and points the request URL at the trigger address Dify provides for the plugin. Select only the event types the workflow needs, and take the exact scope names and field labels from the plugin listing and Slack's own app setup pages, since they change over time. Install the app into the target workspace and record the bot identity used for replies. The step is done when Slack reports the request URL as verified and the app is installed in the workspace.
Connect the plugin with Slack credentials
In Dify, the builder enters the Slack credentials the plugin asks for, typically the bot token and signing secret from the Slack app, into the plugin's authorization fields. Store them only in Dify's credential settings, restrict access to the workspace owners who manage the app, and rotate them if the Slack app is reinstalled. Confirm that the field names match the plugin listing exactly. The step is done when the plugin status shows as connected and no authorization errors appear in the plugin logs.
Build the workflow with the trigger and a reply tool
The builder creates a workflow in the Dify console, adds the Slack trigger node as the start point, and connects the event fields it needs to the downstream model or logic nodes. Add a Slack reply tool node at the end, bound to the same credentials, and map the target channel to the channel identifier of the test channel only. Keep the prompt and output mapping in the workflow so reviewers can read each step. The step is done when the workflow validates in the editor without unresolved nodes or missing variables.
Test with one channel and read the run log
Post a test message in one designated Slack channel that the app has been added to, then open the workflow run log in Dify. Confirm that the event reached the trigger node, that each node produced the expected output, and that the reply tool posted to the test channel and nowhere else. Check that no other channel receives the reply before you widen the scope. The step is done when the run log shows a successful execution and the reply appears in the test channel with the expected content.
Scoping Slack events to specific channels and workflows
A single shared support channel is the simplest scope: one app, one workspace and one channel the app is invited to. The main exposure is who can post there. Every member who can write to the channel can cause the workflow to run, so the workflow's inputs, the model it calls and the tools it uses become reachable from each of those messages.
- Channel membership: Confirm which members, and any external guests, can post in the channel, since each of them can trigger a run.
- Bot invitation: Confirm the app is invited to this channel only, and that no workspace-wide install setting adds it to other channels.
- Message filtering: Decide whether the workflow inspects message text before it calls the model, and test with messages that should be ignored.
- Reply target: Confirm the reply tool posts back to the originating thread or channel, and not to a default channel set elsewhere.
- Plugin limits: The plugin does not decide who may post. Scoping is only as strong as the Slack membership and the workflow logic you build around it.
Before go-live, export the channel's member list, confirm the app's invitation list and run one test from a guest account if guests are allowed.
Several team channels with separate workflows raises a design question first: whether one app serves all channels or each team gets its own app. One app is simpler to operate but puts every workflow behind one configuration and one set of credentials. Separate apps keep a mistake in one team's setup from reaching another team's channel, at the cost of more configuration to maintain.
- App count: Decide between one app per workspace and one app per team, and record the owner of each channel's app.
- Channel to workflow map: Keep a table listing each channel, the app invited to it, the workflow it triggers and the knowledge bases and tools that workflow uses.
- Event filtering: Confirm each workflow checks the channel identifier, so an event from one team never runs another team's workflow.
- Shared credentials: If several workflows share model or tool credentials, a misrouted event still uses those keys. Scope credentials per team where the platform allows it.
- Plugin limits: Confirm in testing how the plugin handles repeated or duplicate event deliveries, since the plugin documentation does not settle this for you.
Test each channel with a message that should trigger only its own workflow, and keep the results with the channel map.
A private channel often holds content that should not reach a shared model or a multi-team knowledge base. Slack membership controls who can see the messages. It does not control where the message text goes once a workflow reads it. The boundary therefore has to be built in the workflow and the model configuration, and the plugin's own settings do not enforce it.
- Private channel membership: Confirm the app is invited only to private channels whose data your policy allows the workflow to process, and review that list when membership changes.
- Model endpoint: Confirm which model provider or self-hosted endpoint this workflow calls, and that the endpoint is approved for that class of data.
- Knowledge base access: Confirm the workflow does not retrieve from shared knowledge bases when it handles private-channel events.
- Logs and traces: Check whether run logs and any tracing integration store message text, and who in your organization can read them.
- Plugin limits: The plugin does not classify content or stop a workflow from sending text to a model. Enforce the boundary in workflow branches, model settings and log access, then verify it with test messages.
Before enabling the integration, ask your security team to review the full data path from the private channel through the model, the tools and the logs.
Mapping Slack event fields to Dify workflow inputs and replies
This table pairs each Slack event item with where it appears in the trigger output, how a Dify workflow uses it, and what to confirm before building. Read it as a checklist: the field names come from the plugin, so verify each one against the installed version before wiring nodes together.
| Slack item | Where it appears in trigger output | How the workflow uses it | What to confirm |
|---|---|---|---|
| Channel ID | Event payload field identifying the channel where the message was posted | Scopes the run and selects the reply destination, and can be checked against an allowlist in a condition node | Exact output field name in the installed plugin version and whether it is a channel ID or a display name |
| User ID | Event payload field identifying the Slack user who posted or triggered the event | Identifies the sender for logging, routing or permission checks inside the workflow | Whether the field is the Slack member ID and whether bot-authored events carry a different identifier |
| Identity mapping | Not a trigger field. Slack user IDs stay in Slack unless your team builds a lookup | Look up a Dify account or role from the Slack user ID before any step that reads private knowledge or calls tools | Who owns the mapping table, how it is updated when staff leave, and whether Dify access rules are enforced for the mapped user |
| Message text | Event payload field containing the raw message body | Passed as the query or input variable to the LLM or agent node, often after trimming bot mentions | Whether formatting such as mentions, links and code blocks arrives as raw Slack markup and how long messages are handled |
| Event type | Event payload field naming the Slack event, such as a message or mention event | Branches the workflow so only the intended event types start a run | Exact event names the plugin forwards and which subscriptions must be enabled in the Slack app |
| Thread timestamp | Event payload field that identifies the parent message of a thread, when present | Lets replies stay in the same thread instead of posting to the channel root | Whether the field is empty for top-level messages and how the plugin reports it for replies |
| Reply target | Not a single trigger field. Built from channel ID and thread timestamp in a workflow step | Passed to the Slack reply tool as channel and thread parameters so the answer lands in the right place | Exact parameter names of the reply tool and whether the bot needs permission in each channel |
| Event verification and retries | Handled by the trigger plugin and Slack request signing, not by workflow nodes | Duplicate events should be detected so one message does not produce two answers | Whether the plugin deduplicates retries and what your Slack app does when the public trigger URL is unreachable |
Why the public trigger URL is the part self-hosting teams miss
The step most self-hosting teams miss is the public address of the Dify instance itself. Dify's environment variable reference lists TRIGGER_URL alongside the console, service API and app URLs, and it must be set to the address that upstream services call. For a Slack trigger, that upstream service is Slack. Slack's servers have to reach your Dify instance from outside your network, so the value cannot be an internal hostname or a container name that works only inside Docker. Treat TRIGGER_URL as a network design decision made before the Slack app is configured, not as a default to accept.
Plan the path from Slack to the instance end to end: a DNS name that resolves publicly, a reverse proxy or load balancer in front of Nginx, TLS termination at that edge, and a firewall rule that admits inbound HTTPS from the source ranges Slack uses. Confirm with Slack's own documentation which addresses it calls from and whether your network policy can allow them. Decide early whether TLS ends at your load balancer or inside the cluster, because certificate renewal, header forwarding and the TRIGGER_URL scheme must all agree. If the instance sits on a private network, a public tunnel or relay is a different architecture with its own access and logging controls, and it should be reviewed as such.
Before you expose the endpoint, confirm the exact behavior of event verification in the Slack trigger plugin, including how it validates request signatures, which headers it reads, and how it responds to unverified requests. Check this against the plugin's current documentation and a test workspace, not assumptions from other Slack integrations. Also confirm which routes the plugin registers on the public address, so that only the trigger path is reachable from outside while the console and administrative endpoints stay internal. Record the result as a test you can repeat after each Dify upgrade, because version changes can alter trigger routing.
Securing the Slack trigger on a self-hosted Dify
A Slack trigger gives people in a Slack workspace a path into your Dify workflows, so the exposure has to be limited on several fronts at once. The cards below cover the network path Slack reaches, where credentials live, how outbound reply calls are filtered, the Slack scopes granted, and who inside Dify can change what an event does.
Limit public exposure to the trigger path
A self-hosted instance must expose the address Slack calls back to, set through TRIGGER_URL, and that address is the only inbound path this integration needs. Review your reverse proxy or load balancer so that only the trigger route is published to the internet, while the console, service API and admin paths stay on your internal network or behind access controls. Confirm this with a test from outside your network before you go live, because a broad proxy rule can expose more than the trigger.
Keep Slack credentials out of workflow text
Store the Slack app credentials in Dify's credential storage through the plugin configuration, not in prompts, code nodes or variables that anyone with workflow edit rights can read or export. Dify's SECRET_KEY signs sessions and JWTs and encrypts OAuth credentials, so treat it as a protected secret and never change it casually, because changing it after deployment logs out all users. Confirm which values your team can see in the console and rotate the Slack token if it has ever been pasted into a workflow.
Filter outbound reply calls through the SSRF proxy
Reply tools make outbound HTTP calls from the Dify backend to Slack, and a workflow can point a tool at any URL it is allowed to reach. The SSRF_PROXY settings route these requests through a proxy that blocks internal and private IP ranges, which reduces the chance that a crafted event or a misconfigured tool reaches your internal services. Confirm the proxy is active in your deployment and test that a reply to an internal address fails as expected.
Grant only the Slack scopes the workflow needs
Create the Slack app with the smallest set of scopes that covers the events the trigger receives and the messages the reply tool posts. Each extra scope widens what a compromised token can read or write across the workspace. Review the scope list with your Slack administrator, and document which channel types and event types each scope enables so that a later change to a workflow cannot quietly depend on a broader permission.
Scope triggers per channel and per workflow
Restrict which channels can start a workflow by limiting the events the Slack app subscribes to and by checking channel identifiers inside the workflow before any tool acts. Treat the channel as part of the authorization decision, not only as a routing detail. Ask whether your Dify version and the trigger plugin support the channel scoping you need, and test it with a channel outside the intended set.
Control who can edit triggered workflows
Workspace roles and workflow edit rights decide who can change what a Slack event does, including which tools run and what data they send. Anyone who can edit a triggered workflow can effectively redirect a Slack event to a different action, so limit edit rights to a named group and review changes before publishing. Confirm the role model available in your edition, because the Community edition is limited to a single workspace and access options differ in Enterprise.
Common Slack trigger failures and how to fix them
This table pairs each common symptom with a likely cause and a fix to verify, so you can work from what you observe to where to look. Treat every fix as a check against the plugin listing, your Dify logs or your own environment, not a guaranteed remedy. The main takeaway is that most failures trace back to reachability of the trigger URL, app membership in each channel, or field mapping inside the workflow.
| Symptom | Likely cause | Fix to verify |
|---|---|---|
| Slack events not arriving | TRIGGER_URL points to an internal hostname that Slack cannot reach, or the public address is blocked by a proxy or firewall | Confirm TRIGGER_URL is the public address upstream services call, then test that the endpoint answers from outside your network |
| Slack events not arriving | Event subscription request URL was saved before TRIGGER_URL changed | Check the Slack app's event subscription settings against the current trigger address and resubmit the URL |
| Workflow does not start in some channels | The Slack app has not been invited to those channels | Invite the app to each target channel, then send a test message and check the Dify logs for the incoming event |
| Workflow does not start in some channels | Scope or channel filter in the trigger configuration does not match the channel where the message was posted | Compare the filter values in the plugin configuration with the channel ID shown in the event payload |
| Replies posted to the wrong place | Channel or thread timestamp field is mapped to the wrong workflow variable | Trace one test run node by node and confirm the reply tool receives the channel and thread values from the trigger output |
| Replies posted to the wrong place | Reply is sent to the channel while the workflow expects a thread, or the reverse | Review the reply tool's thread option and test with a message that starts a thread |
| Outbound reply blocked | The SSRF proxy rules block the request to the Slack API, or a corporate egress proxy filters it | Check the SSRF proxy settings and related logs in Dify, then confirm your egress policy allows the Slack API domain |
| Events fire after a Dify upgrade | New or renamed variables or changed plugin behavior after moving to a newer release | Read the release notes for the target version, compare your .env with .env.example, and back up before retrying |
Questions teams ask before connecting Dify to Slack
Can an internal team build a Dify Slack integration on its own?
Yes, if the team already runs Dify and has someone comfortable with Slack app administration, Docker Compose and workflow design. The Slack trigger plugin is listed in the Dify Marketplace as a langgenius plugin, so the platform side is a plugin install and configuration rather than custom code. The harder parts are the Slack app setup, making the instance reachable from Slack, and testing reply behavior across channels. Teams without a Slack admin or an owner for the public endpoint usually need those people lined up before the build starts. A partner can take on the whole path, but an internal team with those skills can do it without one.
What drives the effort of a Slack integration in Dify?
Four things move the effort most: the Slack app approval process inside your organization, exposing the trigger address safely, the number of channels in scope, and the reply logic. Each channel adds routing rules, test cases and an owner who confirms the behavior. Reply logic that calls tools, handles errors or posts into threads takes longer to test than a single echo flow. Approval cycles depend on your Slack administrators and security review, so ask your Slack workspace admins how they approve new apps before estimating dates.
Why does a self-hosted Dify need a public trigger URL for Slack?
Slack sends event requests to an address it can reach over the internet, so the Dify instance must expose a URL that Slack can call. The environment variable TRIGGER_URL is one of Dify's common URL settings, and it must be set to the address upstream services call. If the value is wrong, events will not reach the workflow even when the plugin is installed correctly. Plan the hostname, TLS termination, reverse proxy rules and which paths are open to the internet before anything else, and review that exposure with your security team.
What does the client need to provide for this integration?
The client needs a public hostname that routes to the Dify instance with valid TLS, a Slack workspace administrator who can create or approve the Slack app, and named owners for the workflow and for each channel in scope. The workflow owner decides what the bot may read and reply to, and channel owners confirm behavior before channels go live. Access to the Dify console, the server or Compose host, and the secrets used for the Slack app is also needed. Confirm each of these with your own teams, because the names and approval paths differ by organization.
How long does a Slack integration take to deliver?
Duration depends on scope: how many channels, how complex the workflow and tool calls are, how long Slack app approval takes, and how much testing your owners require. A single channel with a simple reply flow is a much smaller job than several channels with tool calls and per-channel rules. Ask any provider for a written timeline tied to a written scope, and check which steps depend on your own approvals, such as the hostname, firewall change and Slack app review. Those dependencies often set the schedule more than the build does.
Is the Community edition enough for a Slack integration?
The Community edition can run the Slack trigger plugin for one workspace, since the pricing page lists it as free and limited to a single workspace. It runs anywhere Docker runs, so a single Docker Compose deployment with a public hostname can serve this use case. Enterprise adds SSO, multiple workspaces, advanced security, a commercial license and professional support, and it is deployed on Kubernetes for high availability. Choose Enterprise if you need multiple Dify workspaces, SSO for the console, or a support commitment, and confirm current edition terms on the pricing page before deciding.
How does a Dify Slack integration differ from a Slack bot inside another platform?
A Dify Slack integration runs your workflows on infrastructure you operate, where the prompts, tool calls and knowledge bases stay under your control. A Slack bot built into a SaaS automation or chat platform runs on that vendor's hosting and terms, which may be simpler to start but changes where data flows and who can change the logic. With Dify, you also own the public endpoint and its security, so you take on patching and access review. Compare data residency, audit needs and operational ownership with your security and compliance teams before choosing.
How DeployOpen scopes and delivers a Dify Slack integration
DeployOpen plans and delivers the Slack trigger and tool plugin work inside your own self-hosted Dify, in infrastructure you control. We start from the channels, events and reply actions your teams need, then write the scope, build and test the flows, and hand over runbooks your operators can keep using.
How we scope
- Inventory the Slack channels, event types and workflows that will start Dify runs
- Confirm the public address for TRIGGER_URL and how your network reaches it
- Record which tools the agent may call in Slack and which actions stay read-only
- Agree the scope in writing before work starts, since engagements are fixed-scope
How we build
- Install and configure the official Slack trigger plugin in your workspace
- Set up event subscription and per-channel scoping in a staging instance first
- Test each trigger path, including rejected events from channels outside scope
- Keep Slack credentials in Dify's stored configuration and out of exported DSL files
How we hand over
- Document the Slack app settings, plugin versions and the trigger URL configuration
- Provide a test checklist covering event delivery, replies and failure cases
- Walk your operators through rotating Slack credentials and disabling a channel
- Deliver the configuration record so your team can repeat the setup on another instance
How we support
- Review plugin and Dify release notes against your integration before each upgrade
- Back up the instance before every upgrade, as the Docker Compose guidance advises
- Offer ongoing support, upgrades and continuous testing as a retainer if you want it
- Re-test event scoping after Slack app permission or channel membership changes
