---
title: "How triggers work"
description: "The three mechanisms behind the triggers - webhooks, change detection against a stored snapshot, and polling - and what each means for latency and setup."
canonical: "https://docs.workflow-trigger-extensions.app/how-triggers-work"
---

# How triggers work

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

## The three mechanisms

| Mechanism | Triggers | Latency | Needs a baseline |
| --- | --- | --- | --- |
| Shopify webhook | 25 | Near real time | No |
| Webhook + change detection | 51 | Near real time | Yes |
| Polling | 6 | Up to one poll interval | Yes |

### 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. They are on by default and you
suppress the ones you do not want.

### 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:

1. stores a **snapshot** of the fields you care about,
2. compares each incoming webhook against that snapshot, and
3. 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.

> [!NOTE]
> **Why the first change sometimes seems to be missed.** Comparison needs something to
> compare against. When you enable one of these triggers, the app queues a baseline sync
> that records the current state of the resource. Once that finishes, the *next* real
> change fires normally. If a trigger is enabled and the baseline has not finished
> syncing yet, the very first change may be absorbed into the baseline instead.

### 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 **Settings > Polling Triggers**. They cost one
poll cycle of latency rather than firing instantly.

## 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:

```
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](https://docs.workflow-trigger-extensions.app/plans-and-usage.md).

> [!WARNING]
> **Editing in bulk is the fastest way to exhaust a quota.** A CSV import or a bulk price
> change fires one event per affected record. If you regularly bulk-edit, suppress the
> broad `... Update` triggers you do not use on **Settings > Trigger Settings**.
>
> This matters more than it first looks: once the allowance runs out, everything that
> happens afterwards is **dropped rather than queued**, so one large import can cost you
> the rest of the period's events. See [Plans and usage](https://docs.workflow-trigger-extensions.app/plans-and-usage.md).