A drop lives and dies on the minute it goes live. You have teased it, timed the email, lined up the paid posts, and told everyone it lands at midnight. So you use the feature that sounds like it was built for exactly this: you open the product, set it to Active, and schedule it to publish at 12:00. The one thing you assume is that at 12:00 the product is live everywhere you sell. It is not. Shopify's future publishing pushes the product to the Online Store and stops there. Your POS lanes, your Buy Button embeds, and whatever marketplace or social channel you have connected are all still showing nothing, and you find out when a customer in the store or on the other channel asks where the thing they were promised is.

This is one of those gaps that does not show up until the moment it costs you, and the Shopify community threads about it read like a slow accumulation of the same discovery. Does product scheduling apply to all sales channels. Why can I not schedule a publish in bulk edit for my other channel. How do I make a product unpublish itself when the sale ends. The answers underneath are always some mix of it only works for the online store, you cannot do that natively, use Flow if you are on Plus, or install an app. Merchants are not asking for anything fancy. They want the obvious thing: put it live everywhere at this minute, and take it down at that one.

The scheduler ran exactly as designed. It published to the online store, on time, and left every other place you sell showing an empty shelf at the one moment you had an audience watching.

What Shopify's future publishing actually does

Give Shopify credit for the part it does. In the product editor, under the sales channel section, you can set a date and time for a product to go live, and at that time it will publish to your Online Store. For a single web-only product with no other channel, that is genuinely enough, and it is why the feature feels like it should cover launches. The trouble is everything it quietly does not do, and each limit is invisible right up until it bites.

It is online store only. The scheduled publish does not reach POS, the Buy Button, or any other sales channel, even when those channels support scheduled publishing on their own, so a drop that is meant to hit every surface at once hits one. It requires the product to be Active at the scheduled minute; if the product is still in Draft when the clock strikes, nothing publishes, and a launch dies silently because someone left it as a draft while finishing the photos. It cannot bulk-schedule in any complete way: the bulk editor exposes a scheduled date for the online store, but you cannot set a schedule across your other channels in bulk, so a fifty-product collection launch becomes fifty separate little settings. And most telling of all, it will only ever schedule a product going live. There is no native way to schedule a product to come down.

The unpublish that Shopify will not schedule

Half of running a modern catalog is taking things off the shelf on time. A flash sale product that should vanish when the sale closes. A collab that is contractually live for exactly one week. A seasonal line that should be gone the day the season is over. A limited drop that sells to a cap and then should stop being browsable. In every one of these, the deadline is as real as the launch, and Shopify has nothing native that hits it. Future publishing schedules the up, never the down. So the unpublish falls to a human and a calendar reminder, which means it happens late, or during dinner, or not at all until someone notices the "sale" product still sitting there at full price a week later.

Leaving a product up past its moment is not a cosmetic problem. A finished promotion that is still buyable is a pricing and trust problem. A discontinued product that lingers draws clicks and orders you cannot fulfil. And when you do finally pull it, you inherit the other half of the mess: the retired URL now dead-ends, the same deleted-product 404 that follows anything you take off the store without a plan for where its traffic and its link equity should go instead.

◆ DATA The reason this is worth fixing is that a launch concentrates all its value into a single window. The email, the ads, the anticipation, and the traffic all arrive together, and a product that is missing from a channel during that window does not get a second launch, it just quietly under-sells while the attention is spent. The same is true in reverse: a product that overstays its window keeps taking orders on terms you did not intend. Both the go-live and the take-down are deadlines, and Shopify only lets you schedule one of them.

Why the usual workarounds don't hold

Faced with a native scheduler that only does part of the job, merchants reach for a handful of moves. Each one gives back something you did not want to lose.

"I will just publish it manually at launch time." The honest fallback, and the one that ties a person to a clock. Someone has to be awake and at a screen at midnight, publish to each channel by hand, and hope they do not fat-finger one, and then be back at the end of the window to take it all down. It works exactly as well as the person's attention holds, which is to say not at scale and not at 2 a.m.

"I will use the native future-publish date." The right instinct for the online store, and a trap everywhere else. It lulls you into thinking the launch is handled, so no one double-checks the other channels until a customer flags the gap, and it silently no-ops if the product was left in draft. It also does nothing about the ending, so you have automated the easy half and hidden the hard half.

"I will build it in Shopify Flow." A real option, and gated. Flow can run on a scheduled time and unpublish products, which is genuinely useful, but it is a Plus feature, so most merchants cannot reach it, and building the launch as a flow means wiring triggers, conditions, and a get product data step for each set, then maintaining it. It is closer to the shape of the answer than the native scheduler, and still a build.

"I will install a scheduling app." Reasonable, and a fixed rule bolted to your catalog. A good app will publish and unpublish on dates, which is proof the native gap is real, but it applies its schedule mechanically and does not check whether the product is actually ready to be seen, does not know that this launch clashes with that promotion, and does not decide what to do with a drop that has no stock at go-live. It runs the calendar. It does not run the judgement.

What the automation actually has to do

The real job is not "publish this product on a date." It is "take the whole launch, put it live at the exact minute on every channel it belongs on, only if it is actually ready, take it back down when its window closes, do it in bulk for the whole set, and pull in a human for the calls that are really merchandising decisions." That is a scheduled action, a readiness check, and a reversible take-down, run across a set rather than a single product. As a Dugong playbook, in plain prose, it reads like this: 

# trigger
On a launch's go-live time, and again on its end time,
   for a set defined by tag, collection, or list

# steps
1. Check each product is ready: active, priced, has
   stock or a pre-order plan, not still a draft
2. Publish at the go-live minute to every channel it
   belongs on, online store, POS, Buy Button, and the rest
3. Unpublish the set the moment the window closes,
   across the same channels, for a timed drop or sale
4. Redirect the retired URL somewhere useful instead
   of leaving a dead product link
5. Keep the set in sync as products are added or
   removed from the tag or collection
6. Hold for review a draft at go-live, a drop with
   no stock, or a launch time that clashes with another promo

Six lines. The compiler fills in the rest: reading the whole launch set from a tag or collection instead of one product at a time, confirming each product is genuinely ready before it goes live so a launch never fires a half-finished page, publishing to every channel at the same minute rather than just the online store, scheduling the take-down that Shopify will not, protecting the link when a product comes down, and reversing cleanly if the drop returns. The merchant never sat up at midnight and never touched a per-product date field. They described how a sharp launch manager would run a drop, and let the compiler run it at the minute the calendar actually turns.

◆ NOTE The trap here is scheduling on time alone. A date is not the same as ready. A product that is still in draft, priced at zero, or sitting on no stock should not go live just because the clock said so, and a take-down that leaves a dead URL trades one problem for another. Publishing blindly on a timer ships broken launches; refusing to schedule at all keeps a person chained to midnight. Knowing which products are truly ready to publish, which drop needs its ending scheduled too, and which clash to escalate is as much the point as hitting the minute.

Why this is a compiler problem, not an app problem

There are competent product-scheduling apps on the Shopify App Store, and a store that runs frequent drops should look at one. But the thing that makes a scheduled launch safe is not one more date picker. It is judgement about a specific set at a specific moment: is every product in this drop actually ready to be seen, does this launch need its ending scheduled as firmly as its start, which channels does it belong on, and does its timing collide with a sale you already have running. Those answers change per launch, per channel, and per day, which is exactly what a fixed rule handles badly and a person handles too slowly to keep up with a calendar full of drops.

A natural-language compiler fits because scheduling a launch was never a single action. It is a readiness check, a timed publish across channels, a timed take-down, and a link-safety step, and it has to run in both directions as the window opens and closes. You can describe the whole behavior in a paragraph. You could never keep up with it by hand across a catalog that launches something new every week. It sits in the same family as the sold-out products that sink your collection, where the store has to re-merchandise as state changes rather than freeze the page, and the sold-out variant Shopify still shows, where visibility has to track what is actually buyable instead of a fixed list.

The workflow worth building this week

If you run drops, collabs, flash sales, or seasonal lines, and you have ever watched a launch land on the online store while a channel sat empty, or found a finished promotion still live days later, this is the automation to set up now, because both the start and the end are hard deadlines and Shopify only schedules one of them. It pairs naturally with the launch and merchandising work we have written about, like the pre-order that holds your whole order hostage, for drops you open before stock lands, and the sale you have to start by hand, which is the pricing half of the same timing problem, and it feeds the same flywheel as the Shopify automations no one builds, where the work that compounds is the part merchants never get to.

Describe it the way you would brief a sharp launch manager: at this minute put the whole drop live on every channel it belongs on, but only the products that are actually ready, and at that minute take it all back down and send the old links somewhere useful, and bring me anything that is not ready or that clashes with something else running. That is the whole brief. The compiler does the readiness check, the publish, the take-down, and the link safety, across the set, on time. Your launch lands everywhere at once, and it ends when you said it would, without anyone sitting up to make it happen.

◆ READING If this resonates, two companion pieces: our dispatch on the sale you have to start by hand, the pricing side of scheduling a promotion and reverting it, and the deleted product that 404s your customers, where a product coming down needs its old URL pointed at a live page instead of a dead end.

If you are a Shopify merchant who has built something that publishes a drop across every channel on time and pulls it when the window closes, or you have a story about a launch that went live on the online store and nowhere else, the inbox is open: field-notes@dugong.live. We are collecting case studies for the next issue.