Zapier Slack: Which Order Events Deserve a Channel Message

What a Zapier Slack integration should and shouldn’t notify

A Zapier Slack integration moves an event from Shopify into a channel message the moment it happens. That sounds simple until your order volume grows past a few dozen a day and every one of them starts generating a line in #orders. At that point the question stops being “can I connect Shopify and Slack” — you already can, in about ten minutes — and becomes “which of these events actually deserve someone’s attention right now.”

Most teams building this for the first time route everything through one Zap and one channel: new order in, message out. It works for a week. Then the channel fills with confirmations nobody reads, the person who actually needed to see a failed payment misses it in the scroll, and someone mutes the channel entirely. At that point the automation still runs — it’s just talking to nobody.

This article is for operators at $3M–$30M in revenue running Shopify Plus or an equivalent paid platform, where order volume is high enough that “notify on everything” stops being a convenience and starts being a cost, both in Zapier’s task usage and in the attention of whoever’s watching the channel. If you’re doing a few orders a day, none of this applies yet — send everything to Slack and worry about filtering later. This is for the point where it stops being free.

What you need before you start

You’ll need a Zapier account on a plan that supports Filter by Zapier and multi-step Zaps — the free plan supports single-step Zaps only, so filtering requires at least the entry paid tier. You’ll need Shopify admin access with permission to authorise a Zapier app connection, and a Slack workspace where you (or whoever owns the integration) can add the Zapier app and grant it access to the channels you plan to post into.

Decide your channel structure before you build anything. A single #orders channel that receives every event is the mistake this whole article is about avoiding — plan for at least two channels from the start: one for exceptions that need action (#order-exceptions or similar) and, if your team wants visibility without action, a separate low-priority channel for volume you might glance at once a day. You don’t need Slack admin rights to receive messages in a channel you’re already a member of, but you do need them to create new channels if none of the right ones exist yet.

Finally, have a real sample order ready. Zapier builds its field list from whatever record it pulls when you first connect the trigger, and testing against a realistic order — one with line items, a discount, a shipping address — surfaces formatting problems that a blank test record won’t.

Which order events earn a channel message

The test for whether an event deserves a Slack message isn’t “did something happen” — it’s “does a person need to do something because it happened, and does it matter whether they do it in the next ten minutes or the next day.” Order confirmations fail that test: nothing needs to happen, the customer already got their own email, and the order is a data point, not an exception.

Events that pass the test at most order volumes: a payment that failed rather than succeeded, since it usually means the order needs manual follow-up or will silently drop; a fulfilment exception, such as a warehouse marking an item as out of stock after the order was accepted; a refund or return initiated above a value threshold you set for your own business, since refunds under that threshold are routine and refunds above it usually deserve a second look; and an order flagged by Shopify’s own fraud analysis as needing review, since that’s Shopify already doing the filtering work for you.

Some events sit in between and depend on your operation. A single order over a set value might deserve a message if your team treats large orders differently — confirms stock manually, or checks the shipping address against known fraud patterns — but if every order clears that bar without extra handling, the message is just noise with a dollar sign in front of it. Decide this by asking what a person on your team actually does differently for that order, not by how impressive the number looks in a channel.

What almost never deserves a channel message at volume: routine order creation, successful payment capture, standard fulfilment and shipping confirmation, and customer account creation. These are the events your order management system, your 3PL, and your customer’s own inbox already surface. Routing them into Slack duplicates a signal that exists elsewhere and adds nothing except volume.

Building the Zap: trigger, filter, format, send

Step 1: Connect Shopify as the trigger

Create a new Zap, choose Shopify as the trigger app, and pick a trigger event — New Order is the standard choice for most order-alert routing, though Zapier’s Shopify integration also exposes more specific triggers for events like fulfilment updates, depending on what’s available on your account at the time you build this. Connect your store through Zapier’s OAuth flow rather than an API key if you’re given the choice; it’s easier to revoke access later without touching the Shopify admin. Once connected, pull a sample order and check that fields you’ll need downstream — financial status, total price, customer tags, line item count — are actually present in the sample. If your store uses custom tags to flag VIP customers or wholesale accounts, confirm those tags show up in the sample too, because you’ll likely filter on them.

Step 2: Add a Filter step before Slack sees anything

The Filter step is what separates a Zap that stays useful from one that gets muted. Insert it immediately after the trigger, before any formatting or the Slack action. Set your condition — financial status equals paid, or order total greater than your threshold, or customer tags contains a value you use for flagged accounts. A Filter step stops the Zap’s run entirely when the condition isn’t met, meaning nothing downstream executes and no Slack message goes out.

You can stack more than one condition in a single Filter step, and you can chain a second Filter later in the Zap if you need to combine an “and” with an “or” that the first filter’s rule structure can’t express cleanly. Keep the logic as simple as you can read at a glance six months from now — a Filter with five stacked conditions is a Filter nobody will safely edit later without breaking something.

Step 3: Build the message text

Add a Formatter by Zapier step if you need to manipulate a value — turning a raw currency number into something readable, or trimming a long product title — before it reaches the message. Otherwise, write directly into the Slack action’s Message Text field using Slack’s own markdown syntax: asterisks around text for bold, an underscore pair for italics, and a line break (typed as an actual newline in the field, not a \n string) between each piece of information.

Structure the message so the reason it exists comes first. “Payment failed — Order #10482” reads faster than “Order #10482 — payment failed” when someone’s scanning ten messages in a row. Follow it with the customer name, the order value, and a direct link to the order in Shopify admin — paste the actual admin URL rather than a shortened link, since a shortened link adds a click before anyone can tell if the message even needs their attention.

Step 4: Connect the Slack action and send a test

Choose Slack as the action app and Send Channel Message as the event — this is the standard action for posting into a channel, distinct from Send Direct Message, which goes to an individual instead. Set the Channel field to the specific destination for this event type, not a general channel you’re routing everything into. Zapier will ask whether to send the message as the connected user or as a bot with a custom name and icon; a bot identity makes it obvious at a glance that the message is automated, which matters once a channel has both human and automated posts in it.

Before turning the Zap on, run it manually against your sample order from inside the Zap editor. Check the message actually lands in the intended channel, the formatting renders correctly rather than showing literal asterisks, and the link opens the right order. Only then flip the Zap to live.

The step most teams get wrong

The step teams skip is the Filter, and they skip it for an understandable reason: without it, the Zap works immediately. Connect Shopify’s New Order trigger straight to Slack’s Send Channel Message action and you’ll see order alerts flowing within minutes, which feels like success. It is success, for about a day.

What happens next is predictable. Every order — paid, pending, cancelled seconds later, a duplicate from a customer double-clicking checkout — generates a message. On a store doing meaningful volume, that’s dozens of messages an hour in a channel that was meant to flag the handful that need attention. The team either mutes the channel, which defeats the purpose, or someone goes back in later and adds the Filter that should have been there from the start, then has to explain to the rest of the team why the channel suddenly went quiet and whether that means the integration broke.

The fix costs about five minutes: insert Filter by Zapier between the trigger and the Slack action before you ever turn the Zap on, and set the condition to match the event you decided actually deserves a message. If you’re not sure yet which condition to use, build the Zap with the Filter step present but set to a deliberately loose rule, run it for a few days, and tighten the condition once you’ve seen what real order data actually looks like against it. A Filter set too loose is a five-minute edit later. A Zap built without one is a channel someone already stopped trusting.

What notifying on everything actually costs

Zapier bills on a task model: each time an action step in a Zap runs successfully, it counts as one task against your plan’s monthly allowance, and a multi-step Zap can consume more than one task per trigger event depending on how many action steps execute. A Filter step that stops a run before it reaches Slack means the Slack action never executes for that record, so it doesn’t add to the task count there — which is a second, quieter reason to filter early, beyond keeping the channel readable.

The arithmetic that catches teams out is straightforward once you see it: a Zap with no filtering runs its Slack action once for every single order, all month, regardless of whether any of those messages get read. On a store doing meaningful order volume, that adds up against your plan’s task allowance fast, and Zapier’s behaviour when you exceed it is to pause the affected Zaps rather than run them for free — which means the order that actually needed a Slack alert, the failed payment on the 28th of the month, might get no message at all because the quota ran out on routine confirmations days earlier.

The task math is the practical argument for filtering that sits alongside the readability one: every event you route into Slack without a filter is spending task budget on messages nobody acts on, and that budget is the same budget your exception alerts depend on. Zapier’s current pricing page describes exactly how tasks are counted and priced for your plan — check it directly rather than assuming a number, since plan tiers and their task allowances change. What doesn’t change is the principle: a Filter step isn’t just about a tidy channel, it’s about making sure the Zap that matters still has task budget left when it needs it.

Keeping the channel scannable as volume grows

A channel stays useful only as long as every message in it is worth reading. That threshold moves as your order volume grows, so a routing rule that made sense at a lower volume needs revisiting once it doesn’t. If a channel meant for exceptions starts receiving more than a handful of messages an hour, the rule feeding it has drifted back toward “notify on everything,” even if nobody changed the Filter condition — it can happen simply because order volume itself grew past what the rule was tuned for.

Split by consequence, not by event type. A failed payment and a fraud-flagged order might both belong in the same channel if the same person handles both, or they might need separate channels if finance owns one and support owns the other. Build your channel structure around who acts on the message, not around what field changed in Shopify.

For genuinely high-volume, lower-urgency signals — say, a running count of orders that hit a secondary review queue, where no single one is urgent but the trend matters — consider batching instead of individual messages. Zapier’s Digest by Zapier app collects events over a period you set and sends them as a single summary message rather than one per event, which keeps a channel readable for signals that matter in aggregate but not individually. It’s a different tool from Filter: Filter decides whether an event is worth mentioning at all; a digest decides whether it’s worth mentioning immediately or as part of a batch.

Revisit your thresholds on a schedule, not just when someone complains. An order-value threshold set when your average order was one figure stops meaning the same thing after a pricing change or a shift in product mix. Put a recurring reminder on the calendar of whoever owns the Zap to check whether the channel it feeds is still mostly signal.

How to verify the routing is working

Verification has two parts: does the Zap fire on the events it should, and does it stay silent on the ones it shouldn’t. Test the first by using Zapier’s Zap history, available from the Zap’s detail page, which logs every run along with the data that passed through each step — you can see exactly which orders triggered the Zap, whether the Filter passed or stopped them, and what the Slack action actually sent. Run through a week of history after launch and confirm the pattern matches what you expected: exceptions flowing through, routine orders stopping at the Filter.

Test the second by deliberately creating an order that shouldn’t trigger a message — a test order in Shopify’s own test mode, or a low-value order if your filter is threshold-based — and confirming nothing arrives in the channel. This catches a Filter condition that’s technically working but checking the wrong field, which passes a superficial glance but lets the wrong orders through in practice.

Check task usage against your plan periodically from Zapier’s account dashboard, particularly in the weeks after you first launch the integration or after any change to the filter logic. A sudden jump in task usage without a corresponding jump in real order volume usually means a filter condition stopped matching what you intended — a tag was renamed in Shopify, a status field changed values — and the Zap quietly went back to notifying on more than it should.

Routing Shopify events into Slack through Zapier is one small piece of the broader problem of deciding what your systems should tell a human and when — the same question that shows up in fraud review, inventory exceptions and customer service escalation, and it’s exactly the kind of routing and threshold-tuning work Pointerflow’s AI agents and automation service is built around.