Slack Notifications You Think Work But Secretly Don’t in Make

Slack Notifications You Think Work But Secretly Don’t in Make

ByUS Stacked

1. Triggering Slack notifications reliably inside Make for solo work

The first time I slapped together Slack alerts in Make for solo project tracking, it felt straightforward. Visual scenario builder, Slack connection, one simple trigger. I wired it up to ping me in one of my private Slack channels when a new form was submitted — classic Typeform ➝ Make ➝ Slack.

What I didn’t catch? If the first module was a webhook instantly pulled from a front-end trigger (like a form or a button on a Notion page), and Slack was the last step — the module sometimes wouldn’t fire at all if my message body had even one hidden blank field. No error. Just… nothing sent. Make would report “Success” but Slack wouldn’t get a thing. For a solo operator trying to track leads rolling in, that’s a black hole.

This wasn’t in any docs. It took me toggling back and forth throwing random static text into everything before I noticed the pattern: Empty fields passed as null broke Slack quietly every time. Which is absolutely not how that same message behaves if run with the same nulls over email instead of Slack. So now, before sending anything to Slack, I smash the message through a function module that wraps every field in fallback guards, like:

{{if(empty(1.email); "No email provided"; 1.email)}}

That alone fixed maybe half the issues.

2. Dealing with Make’s silent Slack throttling behavior

If you think you’re going to get three separate Slack alerts instantly, separated by seconds, think again. Even with personal tokens or standard Slack connections, Make will throttle delivery or merge firing logic when you pass too many calls through in a short burst — especially from repeat scenarios inside a loop.

One client had a situation where three webhook pings came in at once. Only one alert ever made it to Slack. Inside the scenario, all three routes showed as properly executed — Slack module ran three times, everything marked green. But in real life? One Slack ping. Quiet. Briefly terrifying when it counted.

After retrying and watching logs more closely, I clocked the webhook executions were happening with timestamp deltas under a second. Slack wasn’t rejecting anything officially — it just self-limited how fast Make calls executed messages.

If you actually need slack messages fired reliably for bulk events:

  • Add a sleep module with a 2–3 second delay inside any loop with Slack messages
  • Optionally include retry logic with a manual status check in Slack after send
  • Use a queue system (e.g. webhook ➝ Integromat webhook buffer ➝ timed release scenario)

You could also cheat: clone the Slack channel connection into multiple Make modules to parallelize. Ugly fix, but yeah — it works.

3. Parsing dynamic values from other apps without message breaking

One day while testing a Make webhook from Airtable to Slack, I used a record text field that looked perfectly safe: “Meeting with Jane – 3:30PM (Room 9)”. Pretty normal, right? Slack module crashed silently. No message posted. No error in Make. I started manually replacing bits until I narrowed it down.

Turns out, stuff like parentheses or colons can trigger issues when passed raw into Slack message blocks, depending on formatting. Especially when your Slack module is set to “Use customizable blocks” mode and you try injecting unescaped characters.

This config silently failed:

{
  "type": "section",
  "text": {
    "type": "mrkdwn",
    "text": "Meeting with {{1.title}} – {{1.time}} ({{1.room}})"
  }
}

Switching it to HTML escaping functions like replaceAll(1.title; ")"; ")") sometimes helped, but the breakthrough was dumping the entire payload through a single Log module just before the Slack module. Raw payload showed that nested quotes were slipping through unescaped. Quietly killed the whole block.

Lesson? Never assume Slack message formatting tolerance. Even simple characters can break the render pipeline.

4. Using Slack bot tokens vs personal tokens in Make

Here’s a thing I didn’t learn until the fifth breakdown: When your Slack connection in Make is made with a personal/workspace token, it inherits your user permissions and rate limits. That means:

  • If your Slack account gets signed out or deauthenticated (e.g. SSO timeout), your Make scenario stops silently
  • You might not be able to post to certain channels, especially private ones
  • Any mention formats using <@U12345> can break if your user doesn’t have permission to mention someone

Switching to a real Slack bot token — one created via Slack app with scopes only for what you need — makes the behavior a lot more predictable. Also, bots don’t get booted during SSO transitions or Slack workspace resets. They just keep working, even when you forget they exist.

The only catch? Make doesn’t make it super clear which tokens are bot- vs personal-type during OAuth connection. You have to cross-check in Slack developer settings or the token string behavior. If your token starts with xoxb- versus xoxp-, you’re good. Bot is xoxb.

5. Slack mentions not pinging the right user randomly

Your Slack alert fires. Message says something like “Hey @john check this”. But no ping. John’s standing right there. Slack didn’t notify him. This happens because Make’s Slack module doesn’t resolve usernames — only Slack IDs.

So when you type @john into your message body, it literally goes as text — not a tagged mention — unless you replace it with <@U123ABC> which is Slack’s internal user ID format.

Here’s what I ended up doing:

  1. In Slack, right-clicked on the user’s name ➝ copied their member ID
  2. Stored that ID in a Make variable or Airtable table field (lighter to centralize)
  3. Used that value in the Slack block like Hi <@{{1.mention_id}}>

The irritating thing is that Slack renders typed @john in the visual preview just fine. But in execution — no ping. Zero notification. Only a ghost-mention.

Weird edge case

If you paste a real mention tag (like <@U123ABC>) pulled from elsewhere, Make sometimes auto-sanitizes it into raw text behind the scenes when you copy-paste into a text field block. Had to switch to set-value module and paste there instead to prevent Make from auto-stripping it. Subtle but maddening.

6. Slack alerts bouncing on self-messages in DMs

If you’re trying to send a Slack alert to yourself (solo monitoring), and you point to your own user ID as the channel, there’s a real chance it bounces. Slack doesn’t permit bot modules or webhooks posting into DMs unless the user has already interacted with the app or bot explicitly.

Oddly, if you’ve already sent one message manually via your bot or run one test, the DM looks like it works. But then a few days later, if the bot never gets manually messaged again, Slack blocks it with a silent fail. No error from Make. Just doesn’t hit.

Safer workaround: create a private alert channel (like #alerts-me), drop yourself in there, and direct all messages there. That way the bot never risks permissions breaking mid-scenario. DMs can be wildly unstable long-term inside Make + Slack integrations.

7. Handling Make scenario errors without stopping Slack alerts

By default, if your Make scenario hits a failure at any step before Slack — even something as dumb as a date formatting mismatch — the whole scenario halts. That includes Slack messages you wanted to send as part of your debug chain.

I’ve started wrapping Slack modules in routers that split from the error-handling path. If anything fails mid-scenario, the error catches and forks to a dedicated Slack fallback, posting message text like:

Scenario failed at module: {{3.moduleName}}
Reason: {{3.errorMessage}}

This way I still get pinged when something goes wrong — even if the failure point is miles upstream from wherever Slack sits. You have to aggressively disable error-stops on modules that shouldn’t halt the scenario. Otherwise, Make kills it all out of the box.

One time I had a webhook fail because of a 520 from a client DNS redirect. No Slack message ever came. But it would’ve, if I’d added the error route properly a few days earlier.

8. Slack message previews show the wrong format during editing

When using Make’s Slack module with custom blocks, the visual JSON editor can sometimes render your entire message looking fine in preview — then render completely wrong in live Slack. No bolds, no line breaks — just a wall of raw text.

Turns out, if you’re editing your Slack block formatting inside the scenario UI, and at any point you hit “Show preview” then cancel a few times — Make saves malformed markdown in the background. It strips out escape slashes or line feeds without warning. You only find this out when your Slack feed turns into a mushy blob of text.

A workaround that seemed to fix 100% of it:

  • Disable all previews
  • Use Raw JSON input mode instead of visual builder
  • Add explicit \n newlines instead of depending on auto line breaks

It’s absurd, but the preview button breaks your final output if you tap it too many times while editing. I only figured that out after going back through logs where the exact same payload had one fewer \n character in production environment than in editing mode.