Changelog

Every trigger in this app so far started from something that happened in your admin: an order was paid, a product was updated. This release adds triggers that start from what a shopper does on your storefront.

Shopify does not send webhooks for browsing behaviour, so these are collected by a web pixel the app installs for you - no theme edit, no code to paste.

Storefront triggers

Setup, permissions and what each trigger sends: Storefront triggers.

• Storefront Product Viewed and Storefront Collection Viewed
• Storefront Product Added to Cart and Removed from Cart
• Storefront Cart Viewed
• Storefront Checkout Started
• Storefront Search and Storefront Search Returned No Results - the second is a live list of things shoppers expected you to sell. A single search fires exactly one of the two, so you can enable both without double counting. How the two search triggers split.
• Out-of-Stock Variant Viewed - a real shopper looked at something you cannot sell them. A restock demand signal, per variant rather than per product. What counts as out of stock.
• Signed-In Customer Visited and B2B Buyer Visited - a returning customer is on your store. Repeat page views collapse into a visit window you choose, per customer or per company. Visit windows explained.

Checkout triggers

Details: Checkout triggers.

• Checkout Error Shown - find out checkout is failing without waiting for a support ticket.
• Checkout Discount Code Rejected - a shopper typed a code and checkout refused it. Usually an expired campaign or a code from an email that was never activated.
• First-Time Customer Order - an order from a customer who has never ordered before, with the customer and the order as native Flow references. It comes from Shopify's order webhook, so unlike the two above it is as reliable as any admin trigger. Listed in the trigger reference.

Custom Storefront Triggers

For anything Shopify does not report at all. Publish your own event from your theme with one line of JavaScript and it becomes a Flow trigger. Step by step, with the snippet to copy: Custom Storefront Triggers.

The clearest case is the cart drawer: Shopify's cart view event only fires on the /cart page, and most modern themes slide a drawer open instead and never navigate there. Publishing your own event when the drawer opens closes that gap. Wishlist adds, size-guide opens and variant switches work the same way.

Only event names you have registered are forwarded, so other scripts on your page cannot spend your allowance. Naming the event and using it in Shopify Flow.

Before you switch these on

• They need the new Storefront Behaviour permission, granted from the Permissions page like any other. What the permission covers.
• Shopper consent is respected. If a shopper has not given analytics consent the event is dropped in their browser and never reaches us - it costs you nothing and starts no workflow. How consent is handled.
• They are much higher volume than admin triggers. A busy store produces more product views in a day than order updates in a year, and every event counts towards your plan. Switch on only what a workflow uses. Plans and usage.
• They are best effort, not guaranteed. A closed tab, a dropped connection or an ad blocker means the event never arrives. Use them for signals and reactions, not for anything where a missed event would be a correctness problem.

Full detail, including how Out-of-Stock Variant Viewed decides what counts as out of stock, is in the Storefront triggers guide.

Generate trigger code with AI

Describe what a custom trigger should do in plain English and let AI write the code. On Developer -> Connections, add your own Anthropic or OpenAI API key; generation runs on your account, and the key is encrypted, never shown again and never run inside your trigger code. Full guide: Generate trigger code with AI. Need a key first? Get an Anthropic (Claude) API key or get an OpenAI API key.

• Grounded in what the trigger actually receives. The generator is told this app's runtime contract, the Shopify Admin API and - once you have captured one - the real event payload, so it writes payload.total_price because it can see the field rather than guessing at a name. What it knows.
• Builds on what you have. If there is already code it edits that rather than starting over, so "now also do X" works.
• Never saves on its own. Generated code lands in the editor as an unsaved change: test it against your captured payload, read what it would fire, then save. Generate a custom trigger.
• Writes the theme snippet for Custom Storefront Triggers, which is the part people get stuck on because every theme names its elements differently. Generate a storefront snippet.

Also fixed

• The Add Trigger list on Metafield Triggers could stay empty for up to an hour after granting a permission, saying no definitions existed although they did. The empty result was being cached; it no longer is, so the list fills the next time you open it. The same applied to the metaobject list. See Metafield triggers and Metaobject triggers.
• Product Published to Channel and Unpublished from Channel missed the first change on a newly created product. The app stores a baseline the first time it sees a record and only fires on a difference from it, and for publications that baseline was never written at creation - so the first publish after creating a product was silently swallowed and only the second fired. Both now work from the first change. Product triggers in the reference.

Two fixes from support tickets - thanks to the merchants who reported them.

• Event History now loads instantly on stores with very high event volume. On stores holding millions of events in their 30-day history, the page could take extremely long or fail to load at all. It now opens in well under a second regardless of volume, with all filters working as before.
• The baseline sync for snapshot-based triggers now starts automatically. Triggers that compare changes against a stored baseline (tags, status, title and similar) could wait indefinitely with "0 records synced" when the trigger was switched on before a workflow used it. Switching such a trigger on now starts the initial sync by itself, so the first real change fires.

The largest release since the app was built, and it changes how you set triggers up.

Custom triggers

When no built-in trigger fits, write your own. Pick a Shopify event, capture a real payload from your store, and write a short transform that decides when to fire and what to send.

• Fire only on your conditions. Not "any product update" - only orders above a value, only products from one vendor, only the changes you actually care about.
• Send Flow exactly the fields you want, shaped how your workflow needs them.
• Pull in data the event does not carry. ctx.shopify() runs an Admin GraphQL query from inside your trigger, so you can enrich an event with anything in your store.
• Test before you ship, against a real captured payload, and see the output and logs side by side.

Your code appears in Shopify Flow as Custom Trigger, filtered by its handle, so one workflow reacts to exactly one of your triggers.

Settings is now the Triggers page

The nine Settings tabs are gone. Every trigger now lives on one page with search, and every one has its own on/off switch.

The old page had two kinds of switch that worked in opposite directions: most triggers were off until you turned them on, but the broad ... Update triggers were on by default with a separate tab of "suppressors" to turn them off. Now there is one rule everywhere: a trigger fires while its switch is on.

• Search by name instead of guessing which tab a trigger was filed under.
• All 83 triggers are switchable. Previously a trigger only had a switch if we had built a row for it.
• Bulk enable or disable, applied to your search results or to everything.
• Permissions are granted where you hit them. Switching on a trigger that needs a permission asks for it right there. If it needs two, you get one dialog covering both.

Nothing you had configured changed, and your old Settings links still work. A trigger you had suppressed simply reads as off now.

Simulate a trigger

Testing a workflow used to mean making the real thing happen in your store - editing a product, placing an order, waiting for a poll. Now you can fire a trigger on demand: open any event in Event History and choose Simulate again.

Simulation goes through the same pipeline a real Shopify webhook does, so your workflow receives exactly what it would in production. Use dry run to preview the payload without firing anything. Simulated events are recorded as tests, so they stay out of your statistics and do not count toward your plan.

Note that a simulated trigger runs your workflows for real - if a workflow tags an order or sends an email, that genuinely happens.

Developer API and MCP

• A Developer page for creating API keys, with connect commands for Claude, Cursor, VS Code and others.
• A REST API to list every trigger with its state for your store, read event history and stats, and check which permissions you have granted.
• An MCP server, so an AI assistant can inspect your setup and simulate triggers in conversation.
• Three access levels, with simulation and running custom trigger code behind their own level, so an everyday read key cannot fire your automations.

Keep your trigger code in GitHub

Connect a GitHub repository and your custom triggers are pushed to it automatically. Edit a file in your own editor and the change comes back into the app. Every version is a commit, so a change is reviewable and reversible, and you can roll back to any earlier version from the app.

Also in this release

• Data sync now says In sync rather than only a record count, with the date of the last full sync in your store's timezone. Seeding happens once; after that the snapshot is kept current automatically.
• Granting Product or Order access switches on that resource's broad Update trigger, so events start flowing straight away.
• A clearer setup guide that follows what you actually do: choose triggers, allow access, build a workflow, watch it run.

Product, Variant & Collection Access is no longer granted automatically. It used to be required, included on install and impossible to remove. It is now optional like every other permission: grant it from the Permissions page, and revoke it whenever you want. Granting it registers the product and collection triggers for your store immediately.

Stores that already had it keep it - nothing to do.

A much faster dashboard

The dashboard no longer reads through your whole event history to draw its numbers. Counts per day, per topic and per status now come from a pre-aggregated summary, and your usage figure is read straight from the counter that actually enforces your plan limit - so it is live and always matches. On stores with millions of events this is the difference between the dashboard timing out and loading instantly.

New help center

Full documentation at docs.workflow-trigger-extensions.app - a reference for every trigger, setup and permission guides, troubleshooting, and step-by-step workflow guides with videos. You can report a bug, request a feature or contact us through a form that reaches us directly, with screenshots attached.

The in-app chat bubble now appears on every page, and steps out of the way when a dialog is open.

Also in this release

• Ask Shopify Sidekick about your triggers - which are set up, why one is not firing, what fired recently, how much of your quota you have used. Read-only; it cannot change a setting.
• Fixed: Customer Note Changed and Customer State Changed never fired. The change was being compared against a value the app was not actually reading. Both work now.
• Fixed: Order Shipping Address Changed silently did nothing unless Customer Data Access was also granted. The app now tells you that up front instead of failing quietly.
• Fixed: stores with a large number of trigger subscriptions could have one missed when granting a permission, or left behind when revoking one.
• The setup guide stays collapsed once you collapse it.
• The app is now listed as Workflow Trigger Extensions. Same app, same install, new name.

Product Variant Cost Changed fires when a variant's cost per item changes - for margin recalculation, repricing rules, or alerting purchasing.

Worth knowing why this needed its own trigger: cost lives on the inventory item, not the product, so Shopify does not emit a product update when only the cost changes. Nothing that watches product updates can see it. This trigger listens to the inventory item directly.

Delivers the product, the variant and SKU, and the old and new cost as money values. Uses the existing Inventory permission and its Settings tab.

Shopify's own inventory triggers report a variant total with no location attached, which makes per-warehouse automation impossible. These three are per location.

• Inventory Level Changed at Location - any change to available quantity at a specific location, up or down.
• Out of Stock at Location - fires when available stock drops to zero.
• Back in Stock at Location - fires when it returns to a positive level.

Every event carries the location and its name, the variant and SKU, and the old, new and delta quantity. So you can unpublish a product only when it is out of stock at your one fulfilment location, or trigger a transfer when one warehouse runs low while another has surplus.

Needs the new Inventory Data Access permission, which also includes Locations Access so events carry the location name rather than just its id. Turning any of them on backfills your current stock levels first, so the first real change fires.

Two triggers for B2B account membership, both using your existing Company permission:

• Customer Removed from Company - fires when a customer is removed as a contact from a company. For offboarding: revoke ERP access, alert the account manager, archive the record.
• Company Contact Updated - fires when a contact's role or details change.

Both deliver the customer and the company together, plus the contact's role.

We deliberately did not add "Customer added to Company" - Shopify Flow already has a native trigger for that.

• Customer Note Changed - fires when the note on a customer is added, edited or cleared, with the old and new value.
• Customer State Changed - fires when an account moves between disabled, enabled, invited and declined.
• Company Location Tax Exemptions Changed - a merchant reported that editing a B2B location's tax settings never triggered anything. Shopify does not emit an update event for that change at all, so this one detects it by polling instead. It fires with the exemptions added, removed and currently in force as a list of codes with readable labels, plus the tax registration id.

Also fixed: the eight draft order triggers were reporting the wrong name in event history.

Routine security maintenance: dependency updates and hardening across the app. No action needed.

• Customer Email Marketing Consent Changed and Customer SMS Marketing Consent Changed - fire the moment consent changes, with the new state (subscribed, unsubscribed or pending), the opt-in level and the timestamp. For GDPR and marketing-compliance automation, or keeping a suppression list in sync.
• Product Published to Channel and Product Unpublished from Channel - know when a product goes live on, or is pulled from, a sales channel. Each event carries the channels added, removed and current as a proper list, so you can iterate over them in Flow rather than parsing text. Fires once per change, not once per channel. Needs the new Publications Data Access permission.
• Market Status Changed - fires when a market moves between draft and active, with the old and new status. Comes with a new Markets tab in Settings.

The largest release so far, and the first with its own email alerts.

Quota and failure alerts

A notification system, opened from the bell on the dashboard. Get an email as you approach your monthly allowance, when you reach it, and when your triggers start failing more than usual. Add recipients beyond the store owner.

Draft order triggers (7)

A new Draft Order Data Access permission unlocks the full draft order lifecycle - built for B2B and wholesale, where the negotiation happens before the order exists.

• Draft Order Update - fires on any change. Suppress it in Settings if you only want the specific ones below.
• Draft Order Tags Added / Tags Removed - tag-based approval gates.
• Draft Order Note Changed - with the old and new note.
• Draft Order Attributes Changed - PO numbers, delivery dates, gift options, with a per-key breakdown of what was added, removed or changed.
• Draft Order Line Items Changed - items, quantities, prices or variants adjusted during negotiation.
• Draft Order Status Changed - transitions between open, invoice sent and completed. Ideal for payment-reminder cadences.

Baselines are seeded when a draft is created, so the first real change after creation fires correctly. Turning on any specific trigger backfills your existing drafts.

Shopify Flow already covers "Draft order created" and "Draft order deleted" natively, so we deliberately do not duplicate those.

Markets and locations (8)

• Market Created / Updated / Deleted - for international and B2B selling.
• Location Created / Updated / Deleted / Activated / Deactivated - warehouses, retail stores and pickup points.

More order and product detail

• Order Financial Status Changed - payment state transitions, for example pending to paid, or refunded.
• Product Type Changed and Product Vendor Changed - each fires on its own, so a workflow can react to a vendor change without running on every product edit.

Also

• Approved for the Built for Shopify badge.
• Stability and performance work, and a batch of UI fixes.

Shopify Flow can tell you a customer or product was updated, but not that a tag changed. These four triggers fire only on the tag change itself.

• Customer Tags Added / Customer Tags Removed
• Product Tags Added / Product Tags Removed

Each one gives you the tags that were added, the ones removed, and the full list before and after - so you can branch on exactly what changed rather than re-reading the record.

All four are opt-in from Settings. The first time the app sees a record it stores a baseline without firing, so switching them on does not flood your workflows with events for tags that were already there.

Also fixed: SKU, barcode and price were missing from the payloads of the four variant change triggers.

Note there is no collection tag trigger - Shopify collections have no tags. Use a collection metafield with Metafield Update instead.