How triggers work

Understanding which of the four mechanisms a trigger uses explains almost every question about timing, setup, and why something did or did not fire.

The four mechanisms

Mechanism	Triggers	Latency	Needs a baseline	Delivery
Shopify webhook	26	Near real time	No	Guaranteed
Webhook + change detection	52	Near real time	Yes	Guaranteed
Polling	6	Up to one poll interval	Yes	Guaranteed
Storefront pixel	14	Seconds	No	Best effort

1. Shopify webhook

Shopify notifies the app the moment the event happens, and the app forwards it straight to Shopify Flow. Discount Created and Location Deleted work this way.

These triggers need no setup beyond the permission, and they each have their own switch on the Triggers page.

2. Webhook plus change detection

This is the largest group, and it is what makes the app useful. Shopify's products/update webhook fires for any product edit and does not say what changed. So the app:

stores a snapshot of the fields you care about,
compares each incoming webhook against that snapshot, and
fires the specific trigger only when that specific field actually changed.

That is how Product Title Changed can fire on a title edit and stay silent on a price edit, even though both arrive as the same Shopify webhook.

3. Polling

Shopify publishes no webhooks for blogs, blog posts, pages, order display status, discount expiry, or company-location tax settings. For these 6 triggers the app checks on a schedule and fires when it sees a difference.

Polling triggers are switched on from the Triggers page like any other. They cost one poll cycle of latency rather than firing instantly.

4. Storefront pixel

Shopify sends no webhooks for what shoppers do: a product page viewed, an item added to the cart, a search that found nothing, an error shown at checkout. For these 14 triggers the app installs a web pixel on your storefront, which reports the event from the shopper's browser.

Three things follow from that, and they set these triggers apart from the other three mechanisms:

Opt-in. They need the Storefront Behaviour Access permission and start switched off. Turning on a Flow workflow that uses one switches it on, as for any trigger. The pixel is installed when the first one is switched on, and sends nothing while none is on.
Consent-gated. A shopper who has not given analytics consent is dropped in the browser, and the event never reaches us, costs nothing and starts no workflow.
Best effort. A closed tab, a dropped connection or an ad blocker means the event never arrives, and there is no retry. Use them for signals and reactions, never where a missed event would be a correctness problem.

They are also far higher volume than admin events. See Storefront triggers before switching one on.

What arrives in your workflow

Field-level triggers deliver the old and the new value, so you can branch on the change itself without a follow-up lookup:

yaml

Old price: 19.99
New price: 24.99
SKU:       WIDGET-BLUE-M

List-shaped changes are delivered as structured objects rather than comma-separated text, so you can iterate and branch on them in Flow. Order line item changes, publication changes, and company-location tax exemptions all work this way.

Ordering and duplicates

Events are deduplicated on Shopify's event id, so a redelivery does not fire your workflow twice.
The app applies a short per-store rate limit so a bulk edit of thousands of products does not overwhelm your workflows. Events are queued, not dropped.
A bulk operation that changes 5,000 products produces 5,000 events and consumes 5,000 of your monthly quota. See Plans and usage.
Storefront events collapse repeats of the same page view within a short window, and the two visit triggers collapse a whole visit into one event per customer or company.