Triggering Slack Alerts from Make Without Breaking Everything

Table of Contents

1. Use a Slack Bot Token not a Webhook URL by default

If you’re in Make and thinking, “I’ll just paste the Slack Incoming Webhook URL and be done with it,” stop. That works, but it’s limited. You’ll hit permissions walls fast — no emoji reactions, no user mentions, and formatting gets janky. Half the time, mentions come through as plain text, and somebody replies, “who is @U123XYZ?” — which is just Slack’s lovely way of exposing user IDs instead of names when you don’t authenticate properly.

Use the Slack > Send a Message module in Make, and authenticate it with a Slack bot token (via OAuth). That gives the module actual powers — channel access, richer markdown, mentions that don’t confuse everyone. Took me a full hour to realize that you cannot even message a private Slack channel via webhook unless the webhook was manually added to that exact channel by an admin. But a bot? That works — if it’s invited.

Mini bug: if you use a webhook after the Slack channel goes private, Make will say the webhook sent successfully, but nothing shows up. Silent fail.

2. Avoid Make instant triggers unless you control the upstream app

Yes, instant triggers sound great. Run the Slack notification immediately when a new form is submitted, or a new row hits Airtable. But in practice, Make’s “instant” triggers rely on incoming webhooks or magic integrations — which don’t always fire. For example, the Typeform integration says it’s instant, but I’ve seen it delay by 2–3 minutes during peak hours.

Airtable “instant” triggers require a scripting extension and a personal token. And if your team changes the token permissions — poof — no trigger, no error, just no Slack message. So unless you’re dealing with a trigger app you fully control and know nobody will touch, use a scheduled polling trigger instead. Pull every 5 minutes. In workflows that talk to Slack, a five-minute delay usually beats silent failure.

3. Slack rate limiting breaks threads in unpredictable ways

If you’re sending multiple Slack messages in a row — say, a parent message, then replies in a thread — make sure to insert a sleep module or chain them via success paths. Slack will silently drop messages if you hit their rate limits, and you won’t get a fatal error. I once fired six replies to a comment thread in Make, all within 1.5 seconds, and half just… didn’t show up.

Found footage: In the Make execution log, the Slack modules showed green checkmarks. But when I opened the Slack thread, it skipped message #3 and #5, almost like someone deleted posts. Spooky until I read the Slack API docs about rate limiting.

Lesson: If you’re posting threaded messages based on a loop or iterator, always include a sleep action between them, at least 500ms. Better: batch them, or limit to three per run.

4. Mapping Slack mentions requires both object ID and display name

Mentioning a user from a dynamic field (like Airtable or Notion) doesn’t work unless you pass the Slack user ID, not just their email or name. You can’t say “Hi @Jane” and expect Slack to resolve who Jane is — even with full access. You need to pass something like <@U04ABC34F>, the raw ID.

The part that messed me up: I was using Airtable form responses with names, mapping to Slack, and each time the mentions failed silently. Messages went through, but mentions didn’t resolve. The Slack team got confusing alerts like “Thanks @FirstName!”, and literally no one got notified.

Fix: Use the Slack > List User module to build a lookup table. Store emails and Slack IDs in a Make variable, and map from email to ID inside the Make scenario. It’s an extra step, but unless you enjoy bots shouting at nobody, it’s worth it.

5. Use Make router branches to avoid sending noise to all channels

Slack alerts are only useful if they’re not annoying. I set up a scenario to send alerts whenever new leads came in, routing the message to different Slack channels based on lead category (product, support, partnerships). For a week, everything went to #general. I thought the logic worked — the router paths looked clean.

Turns out: I was filtering after the Slack module, not before. So the message module was firing no matter what, and only the follow-up logic got skipped. What I saw on screen looked like this:

Router → [Slack: Send Message] → [Filter] → [Done]

What it should’ve been: Router → [Filter] → [Slack: Send Message]

Make runs the modules in order. Filters don’t gate the previous module’s execution — they just control whether to move forward. A subtle order-of-operations thing, but it matters. Rearranged everything, and now alerts only go to the right team. Nobody yells at me when I test a new partner form anymore.

6. Unexpected HTML formatting shows up when using dynamic fields

I copied a Notion title into a Slack message via the Make Notion integration. When the message showed up, it said:

New Request: Quick notes on API rate limits

Apparently, Notion titles include basic HTML tags when fetched via Make. But Slack doesn’t parse all HTML — only limited markdown and escapes most of it. So instead of showing bold text, you get raw <b> tags.

The workaround was pretty annoying. You can use the Make function replace() to strip tags, like:

replace(replace(title; ""; ""); ""; "")

But of course, Notion doesn’t just use <b> — it could occasionally pull <i>, <code>, and other inline tags, especially from rich text blocks pulled from databases. So I ended up writing a strip-all-tags helper function using regex with replaceRegEx() — not documented anywhere in Make UI, but it works.

Regex that worked: replaceRegEx(title; "<[^>]+>"; "")

Feels dumb to regex Notion titles going into Slack, but here we are.

7. Invite your Slack bot to every channel manually or it cannot post

I wasted half an afternoon debugging why a bot couldn’t post in #sales. Turns out, even with full workspace permission, Slack bots need to be manually added to every private channel they’re supposed to message in. Simply authenticating through Make doesn’t give it access.

The confusing part is that the Make scenario shows no warning. It logs “message sent successfully,” despite nothing appearing. We had a false sense that the automation was live. One teammate even replied to a test alert we assumed landed — it hadn’t.

Quick checklist for Slack bots posting to channels via Make:

Bot must be invited to private channels (use /invite @botname)
In public channels, no invite needed, but permissions still matter
If you rename a channel, double-check bot access doesn’t get dropped
Bot-authenticated Slack module is required — webhooks often fail silently
Make won’t throw errors for channel access issues — test each path manually

It’s a quiet failure, but it breaks trust. If your Slack alerts don’t show up, even once, nobody pays attention to them again.

8. Slack message rendering breaks with smart quotes from rich text fields

This one took longer than it should’ve. A Slack message I sent via Make included this sentence:

“Here’s what the user typed: “I can’t log in.””

But in Slack, it showed as a mess of character codes — and cut off part of the text. Turns out, when rich text fields (like from Notion or some website forms) include curly quotes, apostrophes, or em dashes, Slack doesn’t always parse them correctly. It’s not even consistent: sometimes it renders okay, sometimes it breaks the layout.

Found workaround: Use Make’s replace() to normalize quotes. I started pre-processing all inbound strings with a clean-up step that converts fancy quotes to straight ones.

Example:

replace(replace(content; “; "); ”; ")

It’s tedious. But after that, I stopped getting team messages asking, “Why is the customer shouting in Wingdings?”