Im using Slack as a trigger, I am planning this so different users can use it in slacks VIA dm, i want the bot receive request via DM but also get replies from the bot via them for multiple users, if user A dm the bot that user will receive the reply to its own Dm, but also the same with user B and C etc…if i cant do that how about ill make a channel for each user and use that channel to talk to the bot.
I cant contain all the messages/conversation inside a DM. I need to go out of the dm just to message the bot and receive the messages when it was process via rag and read that on my DM.
Hi @Betty Welcome!
You can try using the BOT mention thing so that each user can mention the bot and interact with it personally, and so if the DMs dont combine you can just use the channel ID for the last check before responding, just make sure to use all the right permissions for your slack app/bot and that is it, i built this and by always checking the channel ID to route the replies back to the correct DM i mean user.
One thing worth adding on top of the channel ID routing: if you’re planning to use an AI agent with memory in your bot, use the Slack user ID as the session key for your memory node rather than the channel ID. This keeps each user’s conversation history completely separate, so a DM from user A never leaks context into user B’s session.
Hi, thanks for replying, app mention is on, my workflow is like this gets a trigger from an app mentionn, direct dm to bot or channel, proccess things in RAG, goes thru an if node if there is items missing or clarification, send it via user. but whenever i reply to the DM of the bot, it wont “hear” the message even if the apps mention is on
i cant converse on it on a DM, i need to go out the of the DM and see the response in a channel
@Betty have you added message.im bot event subscriptions? Although this can cause troubles in a huge workspace but you can try switching your n8n slack trigger to “Watch Whole Workspace”. And again make sure your slack bot has all the required scopes enabled, as mostly slack problems are really related to slack credentials:
@Betty Have you set the webhook URL for trigger on slack correctly? And does it work with all other operations of trigger? (If Yes consider revoking that token and then let me know as if you have everything turned on that issue should be resolved)
@Betty one thing that might explain this: app_mention events don’t fire in 1:1 direct messages with your bot — Slack treats DMs differently from channels. In a DM, users just write to the bot directly (no @ needed), and Slack fires a message.im event instead. so if you’re using an App Mention trigger and expecting it to catch DM messages, that’s the mismatch. try switching your n8n Slack trigger to listen for message.im events for the DM flow, and keep App Mention for channel interactions.
revoked the app_mention in event subscription and also change the trigger to all events, when i dm the bot app it triggers, replies to user under users chat name, not the bot name/chat, when i try to reply under that converstation still cant listen back when i chat
@Betty the “can’t hear replies” issue is almost certainly because when you use the reply button on a bot message in a DM, Slack sends it as a threaded reply with a thread_ts — this is a different event structure from a fresh top-level DM message, and many trigger setups don’t catch it. Quickest way to confirm: send a completely new standalone message in the DM (don’t hit reply on the bot’s message, just type in the main chat box). If that triggers fine, the issue is thread handling.
For the messages showing under the wrong name — double-check that your Slack node is using the bot token, not a user token. With a user token, messages go out under your personal Slack account instead of the bot identity.
@Betty good to know — so it’s not threading and the token is a bot token, that rules out both things I mentioned earlier.
for the “can’t hear back” part: check your workflow’s execution settings in n8n. if it’s set to run one at a time and a previous execution is still running (or stuck), new incoming DMs can get dropped silently without any error. also worth re-checking in your Slack app’s Event Subscriptions page that the webhook URL is still verified and active — after changing event subscriptions, Slack sometimes needs a re-save.
for messages appearing under the wrong name with a bot token — can you check what channel ID is being passed to the Send Message node? DM channel IDs start with D (e.g. D12345), if the value coming from the trigger payload looks different that could explain the mismatch.
@Betty i should not mention, but have you checked the webhook URL your flows are using? As slack only allows 1 URL per slack app, so make sure you handle this correctly as which trigger is getting fired by which client, this can be a bad cause. (verify that in your event subscriptions), also in your DM sending flow make sure the channel ID is coming properly and working, also that starts with D, let me know if this brings some help.
@Betty good find — that filter node is solving the bot-talking-to-itself loop. when your bot sends a reply in a DM, Slack fires another message.im event for that message too, so without filtering your workflow keeps retriggering on its own output.
the fix: add an IF node right after your Slack trigger and check {{ $json.event.bot_id }} — if it has a value, the message came from a bot (yours), so stop there. if it’s empty/undefined, it’s a real user message and you process it normally.
that’s likely why a brand new app didn’t help either — the behavior is on Slack’s side, not the credentials.
Adding to what has already been said, I think this may be a combination of factors rather than a single root cause.
I’d check those pieces together: make sure DM events are actually being handled, not just app_mention; keep the bot_id filter in place to prevent the workflow from triggering itself; and always reply using the original event.channel, especially in DMs.
Each point already mentioned above is valid on its own, and Anshul and Benjamin both raised good points, but putting them together is probably what will make the flow behave consistently across both channels and direct messages.
Hope this helps clarify things a bit.
@tamy.santos good summary. @Betty yeah it’s really all three working together — message.im handling, the bot_id filter to prevent the loop, and routing replies back to event.channel. If you want to pinpoint which piece is still off, check your n8n execution history and look at the raw payload from the trigger — the event type and whether bot_id is present will tell you exactly what’s happening.
