Can Apple Shortcuts change notification sounds on your Mac?

No. Shortcuts on macOS has no “when a notification arrives” trigger, so there's nothing to hang a sound on. As of macOS 26 Tahoe, the automation triggers available on Mac are time of day, alarm, sleep and wake, an email or message arriving, joining a Wi-Fi network, connecting Bluetooth, and a Focus turning on or off. Another app's notification isn't in that list.

The reason this question gets asked so often is that Shortcuts looks like it should work. It has a Play Sound action and a Show Notification action, and both of those are Shortcuts sending something. Changing what you hear when Slack pings you means reacting to a notification another app already posted, and that's the half macOS doesn't expose to Shortcuts.

Two of those triggers come close enough to be worth naming. “Email arrives” and “Message arrives” watch Mail and Messages accounts directly, not the notifications those apps post. They're the only two apps with that treatment, they only fire on the account conditions you set, and no equivalent exists for Slack, Teams, Discord, Outlook, or anything else.

Limit: Shortcuts can play any sound you like at a time you choose. It cannot be started by a notification from another app.

What people try instead, and where each one stops

The three neighbours to Shortcuts hit the same wall. Each of them can make a sound, and none of them gets told that a notification happened.

Automator

Automator has a Play Sound action and it's good at the thing it was built for, a workflow that runs when a file lands in a folder, when a Calendar alarm fires, when a camera is plugged in, or when you press run. Those are the triggers. A notification arriving isn't a trigger, so an Automator workflow that plays a sound for new Slack messages has no way to start.

Limit: same gap as Shortcuts. Automator can play the sound; nothing tells it when.

AppleScript

AppleScript can post a banner and pick the sound that plays with it, which is again a notification AppleScript sends. There's no notification-received event to handle. A script can't subscribe to Notification Center and be called when Slack posts a banner.

One approach circles around this. Notification Center keeps a local database, and a script can poll it and diff what's new. I'm naming it rather than writing it out, because it needs Full Disk Access, the path and the schema have moved between macOS releases, and a poll interval you can feel is a poll interval that costs battery. In my testing it works on the Mac you built it on and breaks the morning after an OS update, which is a bad trade for a sound.

Limit: no supported hook. The database-polling route works until macOS changes the database, and you find out by not hearing anything.

terminal-notifier

This one is a command-line tool that posts a macOS notification from a shell script, with a flag for which sound plays alongside it. It comes up in these searches because the flag looks like a notification-sound setting. It isn't one.

It sends rather than reacts. The sound applies to the notification the script itself posts, and it has no bearing on what Slack, Mail, or Teams sound like, because those apps post their own notifications and never go near it.

Limit: it changes the sound of notifications you generate from a script, and nothing else on your Mac.

What actually can react to a notification

Exactly one mechanism on macOS lets a program notice another app's notification banner: the Accessibility API, which can read the text already visible in Notification Center banners. Everything that works goes through it, or works inside a single app's own API.

Three routes are open, and they're very different amounts of work.

• A per-service script. Skip macOS and talk to the service instead. The best-known version is a Slack bot that watches channel history and plays a file per channel, which I've picked apart in what the slack-sounds scripts on GitHub do. It buys per-channel sounds for a Slack app, OAuth scopes, a process that has to stay running, and the bot invited to every channel you want a sound for. It covers Slack and nothing else on your Mac.
• Hammerspoon. A Lua scripting framework. It can be made to reach notifications, but only by writing and maintaining code against macOS internals that Apple doesn't document, and it stops working silently when those change. What that costs, from having done it, is in using Hammerspoon for notification sounds.
• Chirpy. Chirpy is a native Mac menu bar app that plays a chosen sound when a matching notification banner appears. It reads the text already visible in Notification Center banners through the Accessibility API, matches each banner against rules stored on your Mac, and plays the sound attached to the most specific match. Rules can name an app, a person, a channel, or a keyword, and each rule has its own sound and volume.

Chirpy needs Accessibility access and never Screen Recording, never connects to Slack's or Teams' APIs, and never sends notification content off your Mac. It's $19.99 once, free to try for 3 days without a card, with 30 days to ask for your money back, and it runs on macOS 13 or later. See what the licence covers. If your problem is broader than Shortcuts, start with giving each Mac app its own notification sound.

Can Chirpy hand off to Shortcuts once it reacts?

Yes, as of Chirpy 3.3. A rule can run a Shortcut instead of playing a sound, so the part Shortcuts is missing, an actual trigger, comes from Chirpy instead. Turn it on in Preferences → Advanced, then edit any rule and choose Run a Shortcut. macOS still has no native notification-arrived automation in Shortcuts itself; Chirpy is what watches for the notification and calls the Shortcut you already built. See how the Shortcuts trigger works.

What the scripting route actually costs

I wrote the Hammerspoon version before I built Chirpy, and the code was the easy half. Notification Center's Accessibility tree isn't documented, and when a macOS update moves it, the watcher stops firing and nothing tells you. Silence looks identical to working. You find out you've been unprotected when you miss the message the script existed to catch. Chirpy is the same mechanism with that maintenance done for you, tested against each macOS release, and it leaves the rest of your automations alone.

One setup note. Keep a quiet default and give distinct sounds to the few alerts that have earned an interruption. Assign a sound to everything and you're back where you started, unable to tell any of them apart.