Search the Flow trigger list for "cancellation requested" and nothing comes back.
Return requested is on the list, and Order canceled is there too, although it only fires once the order is already gone. The customer-account cancellation request that Shopify started accepting on 19 June 2026 has no native trigger at all, so a busy Black Friday queue of those requests will never start a workflow on its own.
Think of a house with a doorbell on the front door and none at the back. Visitors at the front ring and someone answers, while anyone knocking at the back waits until a person happens to walk past the kitchen.
I call this the doorbell list. Every admin event that will fire during peak week gets a row, and each row says whether it rings a bell in Flow, needs a person watching the back door, or belongs to another tool entirely.
Introduction
This post builds that list: every Black Friday operational event that Shopify now fires in admin, marked as a native Flow trigger, a staff queue, or an external tool, then frozen before peak week. The dated walk of checkout, inventory, fulfilment, and support gates belongs in A Shopify Black Friday Readiness Checklist for Brands That Already Scale. Choosing the discount engine for the offers you already decided to run belongs in Shopify Automatic Discounts vs Functions for Black Friday Promos. Year-round admin tasks that still hop across five systems belong in How to Fix Shopify Operational Friction When Simple Tasks Still Take Too Long.
Merchant and developer threads this year keep returning to the same gap. Flow is the native ops layer Shopify teaches in Academy, and several 2026 admin events still have no start condition. A missing doorbell is the problem, and a new campaign idea will not install one.
Which events actually ring in Flow?
Shopify Flow is a free app on Basic, Grow, Advanced, and Plus, and a workflow is a trigger, optional conditions, and actions. Most of that surface works once the app is installed.
Two gates still matter for peak week. Send HTTP request needs Grow, Advanced, or Plus, while tasks from custom partner apps stay Plus-only.
Usage limits follow the Admin API limits on the plan, so a scheduled Get product variant data loop that is quiet in September can throttle when every SKU moves on the Friday.
The published trigger list covers the events most peak-week rooms already watch: Order created, Order paid, Order canceled, Return requested, Product variant out of stock, Product variant inventory quantity changed, Fulfillment order placed on hold, Order risk analyzed, Customer abandons checkout, and Workflow error occurred. Trigger names keep Shopify's American spelling, so write them exactly as the reference does.
The events with no bell are the ones that now appear in admin as a filter, a timeline badge, or a metafield edit. Those rows still belong on the list. They just need a person or another tool instead of a native start condition.
Assign each Black Friday event
Write one row per event that will fire in your admin during peak week. A blank cell means the row is not ready.
| Admin event | Native Flow trigger | Assignment before freeze |
|---|---|---|
| Order created or paid | Order created, Order paid | Native: tag, Slack, hold, or route |
| Return requested | Return requested | Native: notify the returns owner |
| Order cancelled after staff or system cancel | Order canceled | Native: release inventory notes, stop a pick |
| Customer cancellation request (self-serve) | None | Staff queue: saved Orders view on Customer request, or a scheduled poll / third-party event trigger |
| Order confirmation email not delivered | None | Staff queue: Inbox owner plus timeline check on high-value orders |
| Variant sold out or inventory quantity changed | Product variant out of stock, Product variant inventory quantity changed | Native: hide, tag, or alert. Pair with the oversell rule, do not replace it |
| Fulfilment order placed on hold | Fulfillment order placed on hold | Native: notify ops with the hold reason |
| Request fulfilment from a custom email supplier | Submit fulfillment request covers app services only | Staff queue, or move the supplier to an app-based service Flow can call |
| Order metafield or status note changed | None | External tool or a scheduled Get-order job. Do not invent a metafield-changed trigger |
| Fraud or card-testing order | Order risk analyzed, after the order exists | External or Plus checkout validation for the block. Flow only for the after-the-fact tag |
| Flow run failed | Workflow error occurred | Native: page the owner with the run URL |
Inventory rows still need a written available-to-sell number. Flow can alert when a variant hits zero, and the hide-or-backorder rule stays a separate decision that the alert supports. That rule lives in How to Stop Shopify Oversells During Black Friday Flash Sales.
Where are the back doors?
Since 19 June 2026, brands selling into the EU can meet withdrawal timing through self-serve cancellation, and staff find those requests on the Orders page under Customer request. EU and UK brands with that switched on now have a queue with a refund clock, and a high-volume store cannot click every order to find it.
Bounced order confirmations are the second back door. Flow has no failed-email-delivery trigger, so a mistyped address that is still valid in form can sit on the order timeline as Not delivered until someone opens the email panel. Peak volume turns that click-through into guesswork.
Stores with email-based custom fulfilment services can prompt staff from Flow, yet Submit fulfillment request only talks to app-based fulfilment services, so somebody still presses Request fulfillment on every order. List those suppliers before Black Friday and decide whether they stay on a staff queue or move to an app-based service that Flow can call.
Order metafield or status note changes have no trigger either, and nobody should invent a metafield-changed trigger to cover them. If the team already edits those fields during peak, put the row on an external poll or accept that a person will notice the change.
Fraud sits at the side gate. Order risk analyzed and Order created run once the order exists, so card-testing fees are already on the statement. Flow can tag and Slack after the fact, while the block itself belongs in Fraud Control, a checkout validation Function on Plus, or a fraud app.
Basic-plan stores can still tag, email internally, and hold fulfilment with native actions. They cannot post a new order to a 3PL or a wholesale portal through Send HTTP request until they move to Grow, or until an app that already owns that connection replaces the hop. If HTTP is the missing action and you are still choosing the plan, use Choosing the Right Shopify Plan before you treat an upgrade as a November patch.
Who answers each door?
Once every row says whether a bell exists, the assignment is a three-way choice.
Native Flow fits when the trigger exists, the action is a Shopify object or a tested HTTP call on Grow or above, and a failed run cannot charge the customer twice. Typical Black Friday natives tag VIP or wholesale orders, Slack a high-value paid order, hold fulfilment when risk is high, notify the returns owner, and page someone when a workflow errors.
A staff queue fits when the event is visible in admin and the team must act within minutes, yet Flow has no start condition. The saved Orders view on Customer request is the clean example, and a weekend Inbox owner for bounced confirmations is the other, so write down the view name, the owner, and the latest hour they will check.
A queue without a rota is an unanswered door.
An external tool fits when you need a scheduled GraphQL poll, a webhook Shopify will not emit, or a write into a system that has no installed Flow action. Make and n8n turn up here because merchants hit item limits, silent failures, and missing triggers inside Flow, and that move is sound when the runner already has credentials, retries, and an owner.
A new Make scenario built on 20 November is a peak-week risk.
Some teams still lack copy and paste inside the Flow editor, and For each loops over Get-data results still break when the variable picker cannot see the list item. Those limits argue for simpler native graphs and against a last-minute HTTP rewrite.
Plus custom partner tasks earn the native column only after a week of production runs, so treat an untested partner action as external until its run log is boring.
What gets frozen, and when?
The freeze date is the one you already use for theme deploys and new apps: two weeks before Black Friday, unless a hotfix has an owner and a rollback.
After that date, nobody adds triggers or HTTP endpoints, including templates from apps that have not processed your live events. Nobody adds scheduled Get-data loops that walk the catalogue every few minutes, because those compete for Admin API budget while inventory and discounts are already moving.
Live workflows stay out of reach of editor experiments as well. Duplicate a workflow, test the copy, then swap it in, because pausing a peak-week Flow while someone is still dragging conditions is how a hold never fires.
Send HTTP request waits up to 30 seconds for a response and then retries. A 3PL that slows on the Friday afternoon will stack those retries until it looks like a fulfilment outage, so prove the endpoint on a weekday batch shaped like peak before you leave it on.
Workflow error occurred is the safety net. Wire it to the same Slack channel as checkout errors, so a failed tag or a failed HTTP call is visible without anyone opening Flow history.
After Cyber Monday, keep the list and add any event that surprised the war room. January is when you reopen HTTP, partner tasks, and the missing-trigger workarounds.
What stays outside the list?
Checkout test orders, 3PL last-dispatch times, and the support rota still need named owners and latest safe dates on the readiness checklist. Promo maths stays on the Discounts page and in Functions, and warehouse available-to-sell remains its own record even when Flow reports a variant at zero.
International checkout rows for duties, currency, and catalogue belong to a market walk, since none of them is a Flow trigger. That job sits in Shopify Markets Black Friday Traps: Duties, Currency, and Catalog Gaps.
A back door stays silent however large the sale gets, so put a name beside it before the Friday.
Conclusion
You can now list the Black Friday events that fire in your Shopify admin, mark the ones Flow can start, and assign each row to a native workflow, a staff queue, or an external tool. Freeze that sheet before peak week. A trigger that does not exist will not appear because the sale is large.
If the HTTP hop, the 3PL connection, or the cancellation-request workaround still has no owner, Integrations and system optimisation is the path for wiring those events before you raise spend. For a wider stack read, book a discovery call.
