Sending Slack Alerts from Make Without Breaking Everything

Sending Slack Alerts from Make Without Breaking Everything

1. Create a proper trigger or Make will never run

Start simple: Know exactly what’s going to trigger the automation. I used a new record in Airtable as my trigger. That part was fine. But unless you set it up with a polling interval that makes sense and a trigger test that shows up in the scenario log, you’re going to sit there wondering why nothing’s happening while your Slack stays suspiciously silent.

I once spent an hour changing everything except the actual issue — the Airtable view was filtered weirdly and didn’t include the test record. Logs showed zero runs. It looked like Make itself was down. It wasn’t. It was me.

Also: You must turn on the webhook if you switch to a webhook trigger. Yes, I forgot. No, Make doesn’t remind you. It acts like everything is fine until you go look and realize your scenario has never run in its life.

“The scenario is active but didn’t run for 3 days” — I only noticed when someone asked why no one got the deadline warning.

2. Start with Slack module authentication before adding anything else

I made the mistake of laying out my scenario with 4 steps — filters, formatters, delays — before realizing the Slack module was disconnected. The Slack connector drops permissions without warning if changed in the Slack app dashboard. Happens more with shared workspace bots after org-wide permission updates. Suddenly the Send a Message module in Make just… disappears.

Best approach:

  • Start a new Make scenario
  • Immediately add the Slack module and authenticate
  • Send a test message (even just to yourself)
  • Then build the rest

If Slack shows the “scope not granted” error mid-setup, delete the connection and re-authenticate from scratch — don’t try to fix it inline. I tried. It wrote phantom tokens into the auth memory and crashed the entire run.

3. Figure out the channel ID manually for private groups

This is still the dumbest part. Make wants the channel’s internal ID, not the name. If the Slack channel is public, Make fetches it. But if it’s private, Make acts like it doesn’t exist — no error, just an empty dropdown.

The solution I use now is to right-click inside Slack, choose “Copy link,” and snag the ID from the URL — it always looks like C012ABCXYZ. Paste that into the Slack module manually.

But here’s the kicker: even if a user makes the bot part of the group, Slack sometimes doesn’t register it unless the bot posts or gets explicitly mentioned. So just inviting won’t always work. Invite the bot, @ mention it once in the channel, then paste the ID into Make.

Edge case I hit by accident:

If you use the Invite via Slack’s UI and then immediately test the Make scenario, it might still fail because Slack hasn’t synced the bot permissions fully. Wait 15–30 seconds or trigger a dummy message to confirm.

4. Handle timestamp formatting or Slack will error silently

You can’t drop in a datetime field and expect Slack to like it. Sometimes Make passes weird ISO 8601 formats like “2024-04-26T18:03:02.000Z” — and Slack lets it through but displays it as raw code. Even worse, if the string includes milliseconds but not the Z (UTC), Slack fails the message silently. No error, no log, just… no post.

Use Make’s formatDate function in a Text > Formatter module or inline.

{{formatDate(now; "MMM D, YYYY @ h:mm A")}}

That works correctly if your Slack instance is set to your real time zone. Otherwise make sure you set the timezone explicitly. Want it to look like Slack’s native timestamps? Use Slack’s block kit with UNIX time formatting (double pain, but doable).

I once had it running perfectly in testing, but the final version sent junk times to the client — because another teammate changed the Airtable date field from datetime to text, and Make didn’t catch the type change.

5. Slack rate limits hit faster than Make tells you

If one message fails due to a Slack rate limit, Make just reports “HTTP error 429” with no detail. But it often retries automatically in the background. Here’s the surprise: if you have parallel execution turned on in Make (Flow Control splitter or Aggregator), it will trigger all Slack sends before rate limiting kicks in.

Slack lets you send roughly one message per second per channel or user. Not exactly — depends on app tier and user load. But I once looped over 18 rows and tried to DM each of the matching users. Only two got the message. Six showed no error. The rest silently skipped.

Solution that mostly works:

  • Add a 2-second delay after every Send Slack Message module
  • Or use a Queue-like Make sequence using tools like Make’s Flow Control – Iterator + Sleep + Aggregator
  • Or just loop inside a repeater with error handling turned on and retries allowed

Only downside: it’ll be slow. But if you want consistent Slack delivery, that’s what’s available.

6. Slack bots can’t see user real names without extra scopes

This one isn’t mentioned in Make or Slack’s UI. If you want your Make-based Slack bot to send messages like “Hey [First Name], here’s your update,” don’t assume the user’s name field pulls cleanly — even with the “User Info by Email” module.

You’ll often get blank values or usernames like U8123ABCD. Turns out you need the users:read and users.profile:read scopes, and in many workspaces, those aren’t turned on by default. Especially orgs with heavy GraphQL-based internal Slack security — something I ran into with a fintech client.

Once you turn those on in your Slack app dashboard and reconnect in Make, the User module starts returning proper display names and even profile fields. That’s where I finally found the user preferred pronouns — which we needed to personalize some automations.

Undocumented scenario: If you don’t include these scopes and try to use a non-existent field, Make just sends null, and the Slack message posts literally like “Hey null, here is your task.”

7. Switch Slack message type when attachments break unexpectedly

If you’re using the “Send Message with Attachments” Slack module in Make and attachments don’t show up correctly, especially with line breaks or buttons, try switching to “Custom Request” module using Slack’s Webhook API format. The core Slack module is pretty limited for anything fancier than plain text.

Things I’ve seen break unexpectedly in the standard Slack Make module:

  • Multiline code blocks
  • Block kit context elements
  • Dynamically generated buttons (anything using external ID)
  • Images that are base64-encoded instead of linked by URL

Use a Make an HTTP Request module with POST to https://slack.com/api/chat.postMessage. Pass in your bearer token (from the Make Slack connection) and raw JSON in the request body. Yes, it’s extra work. Yes, it’s the only way I got buttons to show up inside approval messages recently.

{
  "channel": "C01ABCDXYZ",
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "*New Task Submitted*\nPlease review."
      }
    },
    {
      "type": "actions",
      "elements": [
        {
          "type": "button",
          "text": {
            "type": "plain_text",
            "text": "Approve"
          },
          "value": "approve"
        }
      ]
    }
  ]
}

8. Make runs that silently fail due to Slack team workspace mismatch

If your Slack connection was set up under one workspace and the Slack app is cloned or reinstalled across multiple workspaces, Make might accidentally fire messages into the wrong Slack — or worse, to nobody. I didn’t believe this either until a workflow “ran successfully” for a volunteer group and sent every message to the test workspace from a previous client.

The config looked fine. The Slack connection module was green. Slack even let me send messages. But the OAuth token stored in Make belonged to a different team ID. This edge case popped up because we re-used an automation for a nonprofit event and nobody thought to reauth the Slack connection.

How to avoid it:

  • Navigate to the Slack app dashboard
  • Check the list of workspaces where your app is installed
  • Use a workspace-specific token (re-auth from Make using the new workspace)
  • Run a test message to a unique channel with a weird name to be sure

This is especially painful if you’re working across clients, side projects, or “general” apps that live in multiple Slacks. Don’t trust any token unless you’ve reconnected it within 5 minutes of going live.