Sending Automated Slack Alerts from Make Without Losing Your Mind

Sending Automated Slack Alerts from Make Without Losing Your Mind

ByUS Stacked

1. When Slack messages silently fail in Make without any errors

I had a scenario recently where we were logging inbound leads from a Typeform into an Airtable base, tagging them with a sales region, and sending personalized Slack messages to specific reps depending on the flag. Clean on paper. Looked fine in Make. But messages never showed up in Slack.

No red errors, no HTTP issues, no signs of failure in the Make execution logs. The Slack module showed a green check. But… nothing in the channel, no DMs either. Turns out, if you use user email as the recipient in the Slack module without checking the Invite to workspace option (which isn’t even visible in most setups), the API just silently drops it. The user isn’t in the workspace, but Make doesn’t care enough to warn you.

It only got resolved when I manually invited one of the emails, and boom — 15 messages appeared at once. Apparently, Make had queued them weirdly somewhere?

A Slack API response I saw in a raw output (unparsed) read: { ok: false, error: "channel_not_found" }. But Make’s Slack module returned success for the same run.

This cost me about an hour looking for a phantom delay in Typeform before realizing it was Slack just… ghosting me.

2. Why message formatting breaks differently when using Slack bots

Slack bots behave differently from user tokens, and Make doesn’t push you to consider that when setting up OAuth. If your Slack connection in Make uses a Slack bot token instead of a legacy user token (which you likely generated if you rushed setup), your formatting options start behaving differently — and not all markdown (like *bold* or _italics_) is guaranteed to show up the same.

The lists we generated with dashes kept breaking. One sales dashboard alert message looked like this inside Slack:


• Lead: John Doe
• Region: South
- Needs Follow-up: YES  
- Notes: 📞 Call before 10am

But for some users (logged in on the mobile app), the bullets vanished, the dash-hyphen lines merged, and everything looked like one blob of text.

Quick tip

If your notifications use any consistent formatting, test the message by sending it to yourself in both mobile and desktop. Anything that looks mildly tolerable in Slack’s web interface might destructively reflow in mobile depending on whether it’s a bot or user token.

3. Using Slack lookup modules in Make to dynamically route messages

This should’ve been simple. We had a Make scenario that needed to DM the rep in charge of a region. Since Airtable only had user emails, we used the Slack “Search for user” module to get their Slack ID for the subsequent “Send message” step. Felt clean.

The caveat? The Search for user module fails silently if Slack’s privacy settings are non-default. In one case, Slack was set to disallow email-based user lookup outside admin accounts. The module returns a null user ID, doesn’t throw an error — and then the next step tries to send a message to an empty ID.

Even worse: the Make execution still said “Success.” The only way I caught it was when a rep asked, “Hey am I supposed to be getting alerts? Haven’t seen any this week.”

We fixed it by adding a Router between the lookup and message send step, with a conditional check like: if SlackUserID is not empty. Now it fails out with an email alert if Slack doesn’t return a proper user.

Test your assumptions about identity passthrough. Slack is stricter than you think, especially on Enterprise tiers or restricted workspaces.

4. Message threads behave unpredictably when reusing channel IDs

If you’re piping multiple alerts into the same Slack channel and threading them beneath a parent message, be very careful with how you store and reuse thread_ts (thread timestamp IDs).

I once built a scenario that created daily lead summaries and nested each notification (one per lead) under a header message sent each morning at 9am. This means the morning message’s ts value had to be reusable in the subsequent messages’ Thread timestamp field.

The bug? Some days the parent message failed to send due to a formatting issue (non-escaped ampersand — thanks, CRM export), but Make still tried to parent-thread all the other messages under a non-existent ts ID. Slack silently rejected those — again, no error!

If you’re doing thread-based alert grouping, store the thread_ts dynamically only after successful post. I had to add a check on output["ok"] == true before saving the ts as a variable.

Slack API doesn’t warn on invalid thread timestamps — it just posts into main channel instead. That’s how I noticed all alerts were interrupting conversations.

5. Environment variables help split staging alerts from production

Short version: don’t hardcode Slack channel IDs.

We accidentally sent test automation alerts designed for staging (e.g. nonsensical demo lead names, dummy priority flags) into our real #lead-alerts channel. Twice. I thought I fixed this the first time by adding a production-only filter, but forgot we cloned the scenario structure and missed swapping out the new webhook’s logic.

Now we use an Airtable control table with staging/production flags. Each Make scenario grabs its current mode based on webhook URL and maps Slack destinations using a simple tag match. So [STAGING] - Leads versus [PROD] - Leads, managed in Airtable.

Bonus config table includes

  • Slack Channel ID per environment (e.g. C01AB…)
  • UseThreading flag (yes/no)
  • Fallback user in case lookup fails
  • Enable message logging to Notion or not
  • Send alert on error flag

It’s one extra HTTP step, but the damage saved from ops shouting “Who the hell is NFTesla the Third?” is worth it.

6. Slack rate limits sometimes trigger without observable errors in Make

This was nasty. We scheduled a bulk cleanup action that triggered ~40 Slack alerts within 60 seconds. Every alert used a different path: some direct messages to users, some to shared channels. A few came through, then silence.

Make said everything ran fine. Slack logs showed that most API calls didn’t even reach execution. Turns out, Slack throttles more aggressively per bot token than per user, and if you hit the rate, some messages are dropped pre-flight with 429 — but Make didn’t parse that status code into a visible warning.

I didn’t figure this out until I ran the scenario manually 5 minutes later and saw the same logs claim “executed,” but nothing posted.

Eventually I rebuilt the batch mechanism using a simple sleep() between iterations. You can’t do a 1-second delay inside Make’s visual builder, so I used an Iterator block across dummy list items (e.g. [1,2,3,...]) plus a set variable to delay cycles. Hacky, but stable.

If someone ever adds a native delay module for Make, I’ll probably cry.

7. Slack mentions behave differently depending on channel visibility

This one felt personal. A lead alert message included <@U12345> parsed directly from a Slack user ID. Sometimes this pinged the user. Other times? Flow ran fine, message appeared, but the user never got notified.

Turns out, if you send a message into a private channel that the user isn’t part of, the mention doesn’t trigger any notification — no ping, no red badge, nothing. Not even an indirect mention. It doesn’t error, because the message still posts. But the alert doesn’t reach the human.

We partially solved this by adding a channel invite module before messaging if we detect the user isn’t already present. But Slack’s permissions make that flaky — bots can’t invite users unless they have elevated scopes.

Workaround: Instead of mentions, we resorted to an alias system (e.g. map sales regions to known Slack handles, like @southrep) and ensured those aliases are in the alert channels. Reduces reach, but at least it’s visible.

8. Slack connection tokens occasionally expire without user-facing errors

Every few weeks, I’d start getting random failures on workflows that had been running fine for months. The worst is when alerts stopped landing in Slack but every step showed green in Make. Logs said valid execution, no errors. Until I opened the connection panel and saw this:

⚠️ Your Slack connection “Sales Alerts” was last refreshed 85 days ago.

No actual error thrown. The token had expired in Slack (user’s password reset, internal policy change, whatever), but Make didn’t treat it as invalid unless it hit a live call and returned a 403 — which, for a bot token with basic read-only scopes, didn’t always happen. Scenarios looked idle. I wasted half a day thinking something changed in another system.

Now I manually re-authorize the Slack token every 25–30 days, just to stay ahead of the lurking fail. And yes, I added a Make scenario that reminds me to do this, every 3rd Monday, via… Slack.