How to connect Shopify to Slack when the order volume is the problem

Posting every order to a Slack channel is a lovely thing to do when you are getting three orders a day. It is genuinely motivating, everybody watches it, and it is the first integration most stores build.

At thirty orders a day it is noise. At three hundred it is a channel nobody has opened in months, and the refund that needed somebody's attention on Tuesday is somewhere in it. The interesting question is what replaces it, and the answer is thresholds rather than events.

What we'll cover

• When the order feed stops working
• Thresholds instead of events
• Building it with CodeWords
• Orders that genuinely need a person
• Inventory, which is where money is lost
• The daily number, which people actually read
• Customer data in the channel
• Peak trading, when all of this matters most
• Making it survive
• Limits worth knowing about
• What to set up first
• Frequently asked questions

When the order feed stops working

Worth recognising the moment, because most stores keep the feed long past its usefulness.

Nobody reacts to individual orders any more. The test: when did somebody last do something because of an order message?

The channel is muted by most of the team, which means anything genuinely urgent posted there will not be seen either.

People have stopped scrolling it and check the Shopify dashboard instead, which is faster and more complete.

The signal-to-noise problem inverted. Early on, every order was interesting. Now one in fifty is, and the other forty-nine hide it.

Turning the feed off feels like a loss and is not. What it is replaced by — a daily number and a small set of exception alerts — is more useful and takes less attention.

Thresholds instead of events

The general principle for any high-volume source, and it applies cleanly here.

Alert on the unusual, not the routine. An order far above your typical value, an unusual quantity, a first order from a wholesale-sized account.

Alert on absence. No orders for a period that would be abnormal for your store is the single most valuable alert an ecommerce business can have, because it usually means the checkout is broken and nothing else will tell you.

Alert on rate of change, not on absolute counts. Orders running at half the usual rate for this hour on this weekday is a signal; a raw count is not.

Set thresholds from your own history, per hour and per weekday, since ecommerce traffic has strong daily and weekly patterns.

Recalculate them periodically. A threshold set at launch is wrong within a season, and a stale threshold either fires constantly or never.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which conditions matter, what the thresholds are, and who should be told.
3. Authorize the connection to Shopify with an app scoped to the relevant data, and to your Slack workspace.
4. Describe the exceptions: a test order, a draft order, a refund that was expected, an item deliberately oversold.
5. Test against a development store and a test channel before anything reaches the team.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Orders that genuinely need a person

A short list, and each of these is worth interrupting somebody for.

A high-risk order. Shopify assesses fraud risk, and a high-risk order on a large amount is worth a look before it ships rather than after.

A refund or chargeback above a threshold, to whoever handles them, the same day.

An order that failed to fulfil. Fulfilment errors are silent to the customer until they wonder where their order is.

A payment that failed on a subscription, where you sell them, since the recovery window is short.

An unusually large or unusual order, which may be wholesale, may be fraud, and is worth a human glance either way.

A customer complaint attached to an order, routed to support with the order context already there.

Inventory, which is where money is lost

The category most worth automating and the one most often left to somebody remembering to check.

Low stock on a product that sells, with enough lead time to reorder — which means the threshold depends on the supplier, not on a round number.

Out of stock on something still being advertised. Paid traffic to a sold-out product is money leaving with nothing in return, and nothing connects the two systems on its own.

Oversold items, which happen with multiple sales channels and need somebody to decide what to tell the customer.

Stock that has not moved, monthly, which is capital sitting in a warehouse.

A variant out of stock while the product looks available, which is the version customers find most frustrating and stores notice least.

The daily number, which people actually read

The replacement for the order feed, and the message most teams end up keeping longest.

One message, at a consistent time, with yesterday's orders, revenue, and average order value.

Comparison included. Against the same weekday last week and the same period last year, because a number without context is not information.

Top products and anything anomalous, briefly — what sold unusually well or badly.

Inventory warnings appended, so the one message covers what somebody would otherwise check in three places.

Keep it short enough to read on a phone. A daily summary that fills a screen gets skimmed, and the skim misses the anomaly.

Customer data in the channel

Worth being careful, because order notifications are personal data by default.

Order messages contain names and addresses unless you deliberately exclude them, and a shipping address in a public channel is a real exposure.

Send the order number and a link, not the customer's details, where the channel is broad.

Use private channels for anything involving customer specifics, and check membership.

Remember the copy. A customer exercising a deletion right has their data removed from Shopify, not from your Slack history.

Exclude payment details entirely. They should not be in the message under any circumstances.

Peak trading, when all of this matters most

The rules change during a sale period, and deciding how in advance is better than deciding during.

Raise the thresholds beforehand. Volume-based alerts calibrated on ordinary trading will fire constantly through a peak, and an alert storm on the busiest day is worse than silence.

Keep the absence alert, and tighten it. During a peak, a gap that would be unremarkable in February is an emergency, so the window that triggers it should be shorter rather than longer.

Watch inventory far more closely. Stock that lasts a month normally can go in an afternoon, and the reorder lead time has not changed.

Decide who is watching, and say so. A peak with alerts going to a channel nobody owns is how a four-hour outage happens on the highest-revenue day of the year.

Turn the extra alerting off afterwards, deliberately, or the thresholds stay wrong until somebody investigates why nothing fires.

Write the peak configuration down before the peak. Reconfiguring alerting while the traffic is arriving is not a good position to be in.

Making it survive

Make it idempotent, keyed on the order and event, since Shopify webhooks are at-least-once.

Verify webhook signatures, because the endpoint is public.

Exclude test and draft orders, which otherwise trigger alerts during every experiment.

Handle partial fulfilment and partial refunds as their own cases rather than treating them as complete.

Report the outcome. Alerts sent, thresholds crossed, and anything suppressed as a test.

Limits worth knowing about

API rate limits are enforced on a leaky-bucket basis, so bursts are throttled and bulk work needs pacing.

Webhook delivery is at-least-once and can be delayed or retried, so ordering is not guaranteed.

Inventory across multiple locations complicates any stock threshold, since total stock and available-at-this-location are different numbers.

Some data requires specific app scopes, and a missing scope produces an authorisation error rather than empty data.

Slack rate limits apply, which matters during a sales peak when the temptation to send more is highest.

What to set up first

The absence alert: no orders in a period that would be abnormal for your store, at that hour on that weekday. It is the only message here that catches a broken checkout, and a broken checkout is the most expensive thing that can happen to a store while nobody is looking.

Two habits make the difference. Base the threshold on your own history per hour and weekday, since a flat number fires every night and never during a quiet afternoon. And recalculate it seasonally, because a threshold set in one season is wrong in the next and a wrong threshold gets ignored.

Frequently asked questions

Should every order post to Slack?

Only while the volume is low enough that somebody reacts to individual orders. Once nobody does, the feed hides the messages that matter. Replace it with a daily summary and a small set of exception alerts.

What is the most valuable Shopify alert?

An absence alert — no orders when there should be. A broken checkout produces no error anywhere, and it is the most expensive failure a store can have. Nothing else on the list comes close.

How should inventory thresholds be set?

By lead time, not by a round number. The threshold that matters is how much stock covers the time it takes to reorder that item from that supplier, which differs per product.

Is it safe to put order details in a channel?

Not without thought. Orders contain names and addresses by default, and Slack is a separate copy that a customer's deletion request will not reach. Send the order number and a link, in a private channel.

Why do alerts fire during testing?

Because test and draft orders look like orders. Exclude them explicitly, or every experiment produces alerts and the team learns to ignore them.

Should the daily summary include comparisons?

Yes — against the same weekday last week, since ecommerce has a strong weekly rhythm. A number on its own cannot be interpreted, and people stop reading a summary they cannot act on.

What about paid traffic to out-of-stock products?

Worth alerting on, and it needs both systems: Shopify knows the stock and the ad platform knows the spend. Nothing joins them automatically, which is why the money leaks quietly.

Should alerting change during a sale?

Yes, and plan it beforehand. Raise volume thresholds so they do not fire constantly, tighten the absence window because a gap costs far more, watch inventory more closely, and name who is responsible for watching. Then undo it deliberately afterwards.

What is the risk of leaving peak thresholds in place?

They stay wrong. Thresholds raised for a sale will not fire during ordinary trading, so the alerting looks healthy and catches nothing until somebody investigates why it has been quiet for a month.

Does Shopify's own Slack app cover this?

It covers posting order events, which is the thing worth turning off once volume grows. Thresholds, absence detection, inventory warnings tied to supplier lead times, and anything joining Shopify with your ad spend or support data all need building.

How often should thresholds be recalculated?

Seasonally at minimum, and after any significant change to traffic or range. A threshold set at launch is wrong within a season, and a wrong threshold either fires constantly or never — both of which end with it being ignored.

Related reading

• BigCommerce and CodeWords
• Automating Shopify orders to Google Sheets
• CodeWords integrations and templates