Almost every client we onboard already has a Slack workflow running before we show up, and it almost always does the same thing: something happens, a node fires, chat.postMessage drops a line of text into a channel. That’s a fine start. It’s also maybe a third of what the Slack node in n8n actually does.
The node most people never look past
The Slack node’s default path is Message > Send, with a plain text body. It works, and for a lot of notifications that’s genuinely all you need. But the node covers seven resources: Channel, Message, Star, File, Reaction, User, and User Group, and each one maps to a real Slack API method under the hood, not a synthetic n8n abstraction. Channel operations alone cover archiving, renaming, inviting, kicking, and pulling a channel’s history. Once you know that surface exists, a lot of “we’d need custom code for that” requests turn out to already be a dropdown.
Messages that aren’t just text
Switch the Send operation’s Message Type from Simple Text Message to Blocks and you’re no longer limited to a single string. Blocks accepts the JSON output from Slack’s own Block Kit Builder, which means you can post structured messages with sections, dividers, buttons, and form-style inputs, and then use n8n expressions to fill in the variable parts before it goes out. We reach for this whenever a notification needs someone to actually act on it rather than just read it: a deploy alert with a “rollback” button attached is a different thing than a deploy alert that’s just a sentence.
There’s also an older Attachments message type still available for backward compatibility, with fields like pretext for text that appears above the main block. Slack’s own guidance is to move to Blocks for anything new, and the node’s UI reminds you of that with a notice. Worth knowing it’s there in case you inherit a workflow that still uses it, but not worth building new automations on top of.
Listening, not just pushing
The Slack node sends things into Slack. The separate Slack Trigger node is what lets a workflow start because of something that happened inside Slack, and the two get confused constantly by people new to n8n. Slack Trigger reacts to events: a new message posted to a channel, a reaction added, a bot mention, a file shared, a new public channel created, a new user joining the workspace.
You choose which channel to watch, or you can turn on Watch Whole Workspace to catch events everywhere the app is installed. The node’s own documentation is blunt about the tradeoff here: every event in every channel becomes a separate execution, so turning that on without thinking about volume is how you end up burning through executions on messages nobody needed a workflow to see. We almost always scope this down to one or two channels instead.
One setup detail that trips people up the first time: Slack only lets an app register a single webhook URL. If your workflow is both active in production and open in the editor for testing, Slack will deliver events to whichever URL is currently registered, not both, so you can’t just leave the canvas open and expect test events to show up while production keeps working. The documented workaround is to deactivate the production workflow temporarily, point the trigger at the testing URL, do your testing, then switch it back.
Waiting for a human without building your own polling loop
The operation worth knowing about before you reach for something more complicated is Send and Wait for Response, under the Message resource. It posts a message and then pauses the workflow at that node until someone responds, either right there in Slack or through a form URL n8n generates for the message. You get three response shapes to choose from: Approval (a simple approve/decline button), Free Text, or a Custom Form with whatever fields you define.
This is the exact same shape of problem this blog’s own publishing pipeline solves, just over a different channel. A workflow does some work, needs a human to say yes before it continues, and has to sit there without polling anything in a loop until that answer arrives. Slack happens to build that pause-and-resume behavior directly into one node operation, which is a nicer starting point than wiring it up by hand if Slack is already where your team lives.
Reactions and threads as a lower-noise signal
Not every response needs to be a message. The Reaction resource lets a workflow add, get, or remove emoji reactions on an existing message, and Channel > Replies pulls a thread’s messages if you want to react to what happened in a discussion rather than just the top-level post. We’ve used a reaction add as a cheap “processed” marker on an incoming message channel: a workflow picks up a message, does its thing, and drops a checkmark on it so a human scanning the channel later can tell what’s already been handled without opening a single thread.
The credential detail that will bite you in production
Slack’s credential setup offers two paths: an API access token, which is required if you’re using the Slack Trigger node, and OAuth2, the preferred method for the standard Slack node on operations that support it. Whichever you pick, there’s a specific trap in Slack’s own token settings called token rotation. It sounds like something you’d want turned on for security. In practice, once you enable it, you can’t disable it again, and every token then expires after 12 hours. A credential that silently stops working every half day in production is a bad way to discover this, so it’s worth checking that setting before your workflow ever goes live, not after it breaks.
Scope minimally too. The commonly needed set covers things like chat:write, channels:read, channels:history, reactions:read, reactions:write, and users:read, but a few, like channels:write and stars:read, only function with a user token rather than a bot token. If an operation fails with a scopes error even though you’re sure you added the scope, check whether it’s one of the ones that needs a user token instead.
Where this series goes next
Slack is the integration DepChip fields the most questions about, but it’s rarely the only chat platform a team actually needs. Next we’re covering Discord, which shares some of the same shape (a bot, a trigger, a set of channel and message operations) but comes with its own permission model and its own set of gotchas that don’t map cleanly from what you just learned here.