Changelog

Knowing that something changed is rarely enough. A workflow usually needs to know what it was before: did the price go down or up, by how much, which tag was added, what the metafield said yesterday. This release makes the old and the new value available across the app, and lets a custom trigger start a workflow when nothing happened at all.

Old and new values, everywhere

• Metafield triggers now carry the previous value. Every metafield trigger (generic, product, variant, order, customer) hands Flow Metafield.previousValue next to Metafield.value. It is empty when the metafield was just created. See Metafield triggers.
• Price, unit price and cost changes come with the numbers. Flow conditions cannot do arithmetic, so Variant Price Changed, Variant Unit Price Changed and Product Variant Cost Changed now also deliver delta (new minus old), percentChange and direction (increase, decrease, unchanged). "Price dropped by more than 10%" is now one condition, with no code.
• Product Update, Order Update and Customer Update tell you what changed. They used to say only that the record was updated. They now carry changes: the list of changed fields and, for each, the old and the new value. Tracked fields are title, description, status, tags, vendor, type and handle for products; payment status, fulfillment status, line items, tags, note and additional details for orders; tags, note and account state for customers. Long values are shortened. The list is empty when the update was outside those fields, for example an inventory change.
• Draft Order Line Items Changed now delivers the same line-by-line diff as the order trigger: what was added, removed, or changed in quantity, price or variant.
• Your own custom trigger code sees the old and the new value too. A custom trigger on Product Update, Order Update or Customer Update now receives payload._changes: every tracked field that changed, each with oldValue and newValue. So your code can fire on a transition rather than a state - "status went from draft to active", "the order became paid" - which a condition on the current value cannot express. The sample event you capture in the editor shows the field.

Everything is additive. Workflows you have already built keep working unchanged. The full field list per trigger is in the trigger reference.

Choose which changes fire an Update trigger

Product Update, Order Update and Customer Update have a new setting, behind the gear next to their switch on the Triggers page: Which changes fire this.

• Nothing checked: the trigger fires on every update, exactly as it always has.
• Fields checked: it fires only when one of them changed. Every other update is skipped and does not count towards your plan.

This is also the clean way to stop a workflow from triggering itself. A workflow that starts on Product Update and then writes a product metafield used to start itself again. Narrow the trigger to the fields you care about and that second update no longer fires.

Your other triggers are not affected by this choice. Narrowing Order Update to payment status does not change when Order Tags Added fires.

Custom triggers that run on a schedule

Shopify Flow reacts when something happens. It cannot react when something does not happen, and it cannot see anything outside your store. A custom trigger now can. The editor asks What makes this run: One Shopify event, or On a schedule. On a schedule, your code runs every 30 seconds up to once a day. It remembers what it saw on the last run, can read your store and call anything on the public internet, and decides for itself what counts as a change.

Start from a template and edit the numbers at the top:

• Product, order or customer not updated for N days - stale catalogue reviews, stuck orders, win-back. Each record fires once per quiet period; anything already overdue when you switch it on does not fire all at once.
• A value outside Shopify changed - a supplier stock feed, an exchange rate, a price list. Fires with the value before and after, and the difference and percentage for numbers.
• New item in an RSS or Atom feed - supplier news, a listing feed, a status page.
• No orders for N hours - a heartbeat for your store. Fires once when orders stop and once when they return.

The first run of a scheduled trigger only remembers what it sees, so switching one on never floods your workflows. It appears in Shopify Flow as Custom Trigger, filtered by its handle, and the record comes along as its id. Every run counts towards your plan, whether or not it fires - the editor shows how many runs an interval adds up to. Test runs your code once without firing anything.

Templates for event-based custom triggers

Custom triggers that listen to a Shopify event now have templates as well. Pick one under Start from a template and it selects the event and fills in the code. Each one reads the value before and after the change:

• A product, order or customer field changed from one value to another - for example status went from draft to active, or an order became paid.
• Price dropped by more than N percent - a real markdown, not every price edit.
• Stock fell below a threshold - fires once, at the moment stock crosses the line, not on every sale while it is already low.
• Product metafield number crossed a threshold - a rating fell below 3, a margin went above 40.
• Order paid by a high-value customer - reads the customer's lifetime spend from your store with ctx.shopify() and fires only above the amount you set.

A record's trigger events on its own admin page

New admin blocks show the latest trigger events about the record you are looking at, right on its page in the Shopify admin, each with a short old -> new line such as price: 100.00 -> 85.00. From there you can open the event, or a view of Event History for that one record.

Available for products, variants, orders, draft orders, customers, collections, companies and company locations. Add the block once from the page's customise menu. Triggers that handle personal data are listed without their values. How to add it, with an example on a product, an order and a customer page: Trigger events on a record's admin page.

More AI providers for Generate with AI

Generate with AI now works with Google Gemini and OpenRouter in addition to Anthropic and OpenAI. OpenRouter gives you models from many companies with one key, including any model id you type in. Connect a key on Developer -> Connections: get a Gemini API key or get an OpenRouter API key. As before, generation runs on your own provider account and the key is encrypted and never shown again.

A faster interface, built on Shopify's web components

Every page of the app has been rebuilt on Shopify's new admin web components, the same building blocks the Shopify admin itself uses.

• Faster to load. The app no longer ships its own copy of an interface library. The components come from Shopify, are shared with the rest of your admin and are usually already in your browser's cache, so each page has far less to download before it appears.
• Feels like the admin. Buttons, tables, switches, dialogs and forms look and behave exactly like the ones you use everywhere else in Shopify, including keyboard navigation and screen readers.
• Stays current. When Shopify improves its components, the app picks the improvement up without an update from us.

Nothing moved: every page, setting and link is where it was.

Also in this release

• Grant all and Revoke all on the Permissions page. Grant all asks for every missing permission in a single Shopify dialog instead of one per card. Revoke all asks you to confirm first and tells you what it means: your triggers stay switched on, they just cannot fire until you grant access again.
• Custom trigger code can call the public internet with ctx.fetch(), not only your store with ctx.shopify(). Internal addresses are refused.
• Your custom triggers and your storefront triggers now behave the same: click the row to edit, status on the right.
• The Triggers page shows how many triggers are on next to its title, and the four typed metafield triggers now have their own switches in the list.
• Required fields are marked on the custom trigger, storefront trigger and connection forms.
• Fixed: a date filter in Event History could not be cleared. Removing the date chip or choosing Clear all left the dates applied. Both now clear them.
• Event History rows are plain text rather than blue links. The whole row is still clickable.

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.