Changelog

Workflow Trigger Extensions is now available in four more languages: Swedish, Norwegian, Polish and Turkish. That makes 16 languages in total.

• Nothing to set up. The app follows the language of your Shopify admin.
• Help center and changelog too. The guides, this changelog and the ready-made Flow templates are available in the same languages.

New

• Run for existing records. A trigger normally fires when something changes. On the Triggers page, Run for existing records now fires Product Update, Order Update, Customer Update, Draft Order Update or Collection Update once for every record you already have, or only for the records a search finds, so a new workflow can also work through what is already in your store. You see how many records match before you start and can follow the run until it is done. Every record counts as one event toward your plan.
• Fire trigger now. The app's block on product, order, customer, draft order and collection pages in the Shopify admin has a new button, Fire trigger now. After a confirmation it fires the Update trigger for that one record, which is the quickest way to test a workflow with a real record. It counts as one event.
• A warning before the plan limit, not at it. A third alert next to the usage warning and the limit reached email: when your usage of the last days would reach the plan limit within the number of days you choose (3, 5, 7 or 14, default 7), you get an email that says how many days are left at your current rate. It is on by default and can be switched off in the notification settings under Plan limit forecast. The dashboard shows the same forecast as a banner.
• Plan alerts in the chat too. The three plan alerts also appear as a message in the app's chat, so you find them where you work and not only in your mailbox.
• Four more ready-made custom triggers. Order unfulfilled for N days, Shipment not moving for N days, Date in a metafield reached and Stock fell below a location's own threshold. Pick one as a template when you create a custom trigger, set the numbers at the top and save.
• Newest AI models and a default model. Generate with AI now offers Claude Sonnet 5.5, Opus 5.5, Fable 5.2 and Haiku 5.5, GPT-6.1 Sol, GPT-6 Astra, GPT-6.1 Terra and GPT-6 Luna, and Gemini 3.8 Flash, Gemini 4 Carbon, Gemini 4 Argon and Gemini 3.5 Flash-Lite. On the Developer page, under Connections, you can choose a default model per provider, and the model list next to the prompt starts on it. The models you could pick before are still there, marked as older, and keep working until their provider switches them off.

Improved

• Manual runs in Event History. Events started by Run for existing records or Fire trigger now show the source Manual run and can be filtered by it.
• From an event to its record. The event detail page links to the record in the Shopify admin, in a new tab.

Fixed

• Generate with AI and Claude Fable 5. Claude Fable 5 declined some requests, and the generation failed. Such a request is now answered by another Claude model that Anthropic picks, billed to your Anthropic account at that model's rate.

Fixed

• Company triggers without Customer Data Access. Shopify delivers company, company location and company contact events only to apps that also hold Customer Data Access. Until now a store could grant the Company & Company Location permission on its own and the Company Update, Company Location Update and Company Location Tax Exemptions Changed triggers stayed silent without any hint. The Permissions page now says so on the Company & Company Location card, the Triggers page and the dashboard list Customer Data Access as the missing permission for these triggers, and the company events are connected as soon as it is granted. If one of your company triggers has never fired, open the Permissions page and grant Customer Data Access; the trigger starts working within a minute and nothing changes in your workflow.

New

• Variant changes on Product Update. When a product update changes a variant, the trigger's old and new values now include one item per changed variant field: price, compare-at price, SKU, barcode, inventory policy, taxable, title, options and image, plus a variant being added or removed. Each item names the variant it belongs to, with its ID and title, so a workflow can act on exactly that variant, for example when the inventory policy changes from deny to continue. Turn on Send old and new values in the Product Update settings; Which changes fire this still lets you fire only on the fields you care about, such as variants.inventory_policy.

Improved

• Large updates are reported fully. When one update changes more than a single event can carry, the old and new values hold the first changes and the trigger says so: truncated is true and totalCount tells how many changes there were, while fields still names every field that changed. This applies to Product Update, Order Update, Customer Update, Collection Update, Draft Order Update, Discount Updated, Market Updated, Location Updated, Company Update, Company Location Update, Blog Update, Blog Post Update, Page Update and Metaobject Update.
• Faster metafield triggers. Metafield triggers on products, collections, customers and orders can now read the changed value straight from Shopify's update notification instead of asking Shopify again, one request less per update. Stores are switched over step by step; nothing changes in your setup.

Fixed

• Metafield triggers on very large catalogues. Setting up a metafield trigger on a store with millions of variants no longer stalls in "initializing". The first snapshot now uses a bulk export and completes in minutes.

New

• Ask Sidekick from the setup guide. Every step of the setup guide on the dashboard has an Ask Sidekick button. It opens Shopify's assistant with a ready question about that step, in the language of your admin, and Sidekick answers with your store's own triggers and events. The button shows wherever Sidekick is available in your admin.

• Old and new values on 26 more triggers. These triggers now send the value before and after the change:

  • the update triggers for draft orders, collections, markets, companies, company locations, company contacts, locations, discounts, pages, blogs, blog posts and metaobjects,
  • the inventory triggers at a location,
  • the customer triggers for address, email, name, phone and marketing consent, the draft order triggers for billing address, shipping address and email, and Order Shipping Address Changed.

  Draft Order Update, Collection Update and Market Updated send them when Send old and new values is on in the trigger settings.

Improved

• Failure alerts are on by default. The High failure rate email is now on for every store, new and existing. It goes out when at least 20% of at least 50 events failed within 60 minutes, at most once every 6 hours. Change who receives it, or switch it off, under Notifications.

Page loaders now run independent reads together and fetch smaller database records for lists and dashboard metadata. Trigger lists no longer read transform code or captured samples just to display their names and status.

The Permissions page uses one fresh Shopify scope snapshot, and the metafield picker avoids definition requests for resource types without permission. Existing trigger settings, workflow payloads, refresh controls and authentication are preserved.

Fixed rate-limit tracking when Shopify reports an empty API bucket. Workers now preserve the reported zero balance and wait for capacity instead of treating it as an available budget. Existing trigger settings, event payloads and retry behavior are preserved.

Reduced redundant cache reads when calculating how long to wait for Shopify API capacity.

Improved processing coordination for large product and customer update bursts. Workers can keep more slow-lane events ready to process while preserving existing per-shop concurrency limits, trigger settings and workflow payloads.

Processing slots are now claimed atomically. A worker finishing late can no longer release a slot that another worker has acquired.

Event processing now reads fewer unnecessary database fields and avoids rewriting unchanged draft-order and market snapshots. Existing trigger settings and workflow payloads are preserved.

Fixed a usage-counting issue where the first event could be missed when the quota cache was empty and the store had no recorded event history.

A custom trigger on Metaobject Updated now picks the metaobject definition it listens to, and receives its events. Shopify delivers metaobject events per definition, so the app has to subscribe to each definition separately. Until now only the built-in Metaobject Triggers did that. A custom trigger on the Metaobject Updated event in a store without a built-in metaobject trigger for the same definition received nothing, and "Capture a live event" in the editor waited forever. The editor now asks for the definition next to the event, subscribes to it when you capture or save, and tells you if the subscription could not be made instead of waiting. If you already have such a custom trigger, open it, pick the definition and save once.

The Triggers page opens right away on stores with very large catalogs. The Data sync card shows how many products, variants, customers and orders the app has synced. On a store with hundreds of thousands of variants and a high rate of product updates, counting them could take over a minute, and the page waited for it. The count now runs in the background and is remembered for a few hours. The page opens at once, and until the first count is done the card shows the time of the last sync instead of a number. Triggers and workflows were never affected by this, only the page itself.

Polling-based triggers are checked reliably again on the biggest stores. Variant metafield triggers (and the other triggers the app checks on a schedule: blog posts, pages, expiring discounts, order display status, company metafields) load the store's stored values before comparing them with the current ones. For a store with millions of stored values that step used more memory than the service allows, which restarted it and cost other stores a check now and then. The values are now loaded in bounded batches, so a catalog of any size fits.

A bulk edit on one store no longer delays events for other stores. Events from a store that is sending far more than the app processes at once are moved to a separate queue instead of being retried on the main one. The 21 October delay on Order Attributes Changed and other order events, which was caused by one such bulk edit, cannot recur in that form.

"Which changes fire this" on Product Update, Order Update and Customer Update compares each update with the last copy of the record the app has stored. For a record the app had never stored, it could not tell what changed and let the update through, so a store whose products had never been synced saw every product update fire and count, with only the title ticked.

• A record the app has no copy of is now stored on its first update and does not fire. From the next update on, only the ticked fields fire the trigger, like every other change trigger in the app.
• Saving a field selection now also starts the one-time sync of that resource, the same sync a change trigger gets when you switch it on, so existing records are covered right away.
• With nothing ticked the trigger still fires on every update, as it always has.

If this hit your usage, write to us and we reset it.

A metafield that is already filled when the record is created now fires. A metafield trigger fires when the value changes. A value that was in place from the moment the record was created, for example the answers Shopify Forms saves on a new customer or company, or the metafields of an imported product, used to be stored as the starting point and never fired. It now fires once, with an empty previous value, exactly like a value set a moment after the record was created. The update Shopify sends right after a creation does not fire it a second time.

The app speaks your language

The whole app now follows the language you use in the Shopify admin. Available in English, German, French, Spanish, Italian, Dutch, Danish, Portuguese (Brazil and Portugal), Japanese, and Chinese (Simplified and Traditional). Change your admin language and the app follows on the next page load.

• Every page, dialog and message is translated, including the permission cards, the trigger settings and the custom trigger editor.
• The event blocks on your product, order and customer pages use your language too.
• The workflow templates show their title, description and setup note in your language in Shopify Flow.
• Trigger names stay in English. Shopify Flow shows trigger names in English, so the app does too - the name you see in the app is always the one you find in Flow.

Monitoring: know when a trigger stops working

A trigger that silently stops firing is the hardest problem to notice. The new Monitoring page lets you set a watch on any trigger and get an email when something is off:

• No events - nothing fired for a time you choose. For triggers that should fire every day, like Order Update on a busy store.
• Workflow did not confirm - the trigger fired, but your workflow never reported back. Add the Confirm Workflow Run action as the last step of the workflow, with Event ID set to eventId.
• Failures - events failed for a reason you can fix, such as a missing permission. Temporary Shopify errors do not count.

You get one email when a problem starts, not one per check, and the monitor shows its current state on the page. Monitors are available on every plan.

Also in this release

• Send Flow Status is now called Confirm Workflow Run, with clearer field descriptions. Workflows that already use it keep working unchanged.
• Failure alert emails name the reason and the triggers affected, with a sentence on what to do about it.
• Old and new values on Product Update, Order Update and Customer Update are now a switch. Open the trigger's settings on the Triggers page and turn on Send old and new values if a workflow reads changes. Off, changes arrives empty. Your custom trigger code still receives the old and new values either way.

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.