---
title: "Storefront triggers, step by step"
description: "Step-by-step Shopify Flow tutorials for storefront behaviour: product and collection views, cart changes, checkout started, searches, out-of-stock views, customer visits and custom events."
canonical: "https://docs.workflow-trigger-extensions.app/storefront-trigger-tutorials"
---

# Storefront triggers, step by step

These triggers start from what a **shopper** does on your online store, not from a change in your admin. The app collects them with a web pixel that it installs for you when the first one is switched on.

Read [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md) first: it explains consent, volume and what the pixel does and does not send. Every event counts towards your plan, and a busy store produces more product views in a day than order updates in a year.

**On this page:** [Storefront Product Viewed](#storefront-product-viewed), [Storefront Collection Viewed](#storefront-collection-viewed), [Storefront Product Added to Cart](#storefront-product-added-to-cart), [Storefront Product Removed from Cart](#storefront-product-removed-from-cart), [Storefront Cart Viewed](#storefront-cart-viewed), [Storefront Checkout Started](#storefront-checkout-started), [Storefront Search](#storefront-search), [Storefront Search Returned No Results](#storefront-search-returned-no-results), [Out-of-Stock Variant Viewed](#out-of-stock-variant-viewed), [Signed-In Customer Visited](#signed-in-customer-visited), [B2B Buyer Visited](#b2b-buyer-visited), [Custom Storefront Trigger](#custom-storefront-trigger)

> [!TIP]
> **New to Shopify Flow?**
> Every example follows the same five moves: pick the trigger, add a condition, add an action, turn the workflow on, check Event History. [Your first workflow, step by step](https://docs.workflow-trigger-extensions.app/first-workflow-tutorial.md) shows each of them with screenshots.

![Shopify Flow's trigger picker inside Workflow Trigger Extensions, searched for Storefront](https://cdn-dev.eu.codecreationlabs.cloud/crm-tool/uploads/SjJ78gKLnLlocopCui3Cs62dJbGZ7F1n/e137b492165743c7.png)
*Where you find them: in Shopify Flow choose Select a trigger, open Workflow Trigger Extensions and search for "Storefront".*

## Storefront Product Viewed

Fires when a shopper opens a product page. It carries the product as a reference and the variant that was shown, with SKU and price.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Storefront Behaviour Access** + **Product, Variant & Collection Data Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- Count interest in a product to steer buying or merchandising.
- Feed views into a recommendation or analytics tool that has no Shopify integration.

### What Storefront Product Viewed sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `product` | Product (Shopify) | The product that was viewed. A full Shopify product, so all of its fields and Flow's own product actions are available. |
| `viewedVariant` | Object | The variant shown, with its SKU and price |
| `viewedVariant.variantId` | ID |  |
| `viewedVariant.variantTitle` | Text |  |
| `viewedVariant.sku` | Text |  |
| `viewedVariant.price` | Money (amount, currencyCode) |  |
| `viewedVariant.vendor` | Text |  |
| `viewedVariant.productType` | Text |  |
| `viewedVariant.productUrl` | Text |  |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: Count views in a product metafield

1. Pick **Storefront Product Viewed** as the trigger.
2. Add **Run code** that reads the current value of the product metafield `custom.view_count` from the `product` reference and returns it plus one.
3. Add **Update product metafield** with the returned number.
4. Turn the workflow on.

> [!NOTE]
> **Good to know**
> - Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).
> - This is the highest-volume trigger in the app. Check [Plans and usage](https://docs.workflow-trigger-extensions.app/plans-and-usage.md) before switching it on for a busy store.
> - Two shoppers viewing at the same moment can overwrite each other's count. Treat it as an indicator, not as analytics.

## Storefront Collection Viewed

Fires when a shopper opens a collection page. It carries the collection's id and title.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Storefront Behaviour Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- See which campaign collections get traffic.
- Forward collection views to an external analytics endpoint.

### What Storefront Collection Viewed sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `collection` | Object | The collection that was viewed |
| `collection.id` | ID |  |
| `collection.title` | Text |  |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: Forward views of a campaign collection

1. Pick **Storefront Collection Viewed** as the trigger.
2. Add a **Condition**: `collection.title` **Equal to** `Summer Sale`.
3. Add **Send HTTP request** to your analytics endpoint.
4. Turn the workflow on.

> [!NOTE]
> **Good to know**
> Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).

## Storefront Product Added to Cart

Fires when a shopper adds an item to the cart. It carries the product, the variant, the quantity and the line total.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Storefront Behaviour Access** + **Product, Variant & Collection Data Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- Notice unusually large quantities early, for example a B2B buyer on the consumer store.
- Track add-to-cart for products under test.

### What Storefront Product Added to Cart sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `product` | Product (Shopify) | The product that was added. A full Shopify product, so all of its fields and Flow's own product actions are available. |
| `cartLineEvent` | Object | The variant, quantity and line total |
| `cartLineEvent.variantId` | ID |  |
| `cartLineEvent.variantTitle` | Text |  |
| `cartLineEvent.sku` | Text |  |
| `cartLineEvent.quantity` | Number |  |
| `cartLineEvent.lineTotal` | Money (amount, currencyCode) |  |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: Alert sales to bulk quantities

1. Pick **Storefront Product Added to Cart** as the trigger.
2. Add a **Condition**: `cartLineEvent.quantity` **Greater than** `20`.
3. Add **Send internal email**: `{{cartLineEvent.quantity}} x {{product.title}} / {{cartLineEvent.variantTitle}} was added to a cart`.
4. Turn the workflow on.

> [!NOTE]
> **Good to know**
> - Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).
> - The event knows the cart, not the person. A shopper who is not signed in cannot be identified, and the app never sends names or email addresses from the storefront.

## Storefront Product Removed from Cart

Fires when a shopper removes an item from the cart.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Storefront Behaviour Access** + **Product, Variant & Collection Data Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- Find products that are added and removed again unusually often: a price, shipping or variant problem.

### What Storefront Product Removed from Cart sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `product` | Product (Shopify) | The product that was removed. A full Shopify product, so all of its fields and Flow's own product actions are available. |
| `cartLineEvent` | Object | The variant, quantity and line total |
| `cartLineEvent.variantId` | ID |  |
| `cartLineEvent.variantTitle` | Text |  |
| `cartLineEvent.sku` | Text |  |
| `cartLineEvent.quantity` | Number |  |
| `cartLineEvent.lineTotal` | Money (amount, currencyCode) |  |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: Log removals for a product under test

1. Pick **Storefront Product Removed from Cart** as the trigger.
2. Add a **Condition**: `product.tags` **Includes** `watch`.
3. Add **Send HTTP request** to a sheet or analytics endpoint with `{{product.title}}` and `{{cartLineEvent.sku}}`.
4. Turn the workflow on.

> [!NOTE]
> **Good to know**
> Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).

## Storefront Cart Viewed

Fires when a shopper opens the **cart page** (`/cart`). It carries the cart id, the number of items and the total.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Storefront Behaviour Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- Notice high-value carts.

### What Storefront Cart Viewed sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `cartSnapshot` | Object | The cart contents at the time it was viewed |
| `cartSnapshot.cartId` | ID |  |
| `cartSnapshot.totalQuantity` | Number |  |
| `cartSnapshot.total` | Money (amount, currencyCode) |  |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: Alert on carts above 1,000

1. Pick **Storefront Cart Viewed** as the trigger.
2. Add **Run code** returning `big: Number(input.cartSnapshot.total.amount) > 1000`, because money amounts arrive as text.
3. Add a **Condition** on `big`, then **Send internal email**.
4. Turn the workflow on.

> [!NOTE]
> **Good to know**
> - Most modern themes open a **cart drawer** and never load `/cart`, so on those themes this trigger rarely fires. Publish your own event when the drawer opens and use the Custom Storefront Trigger instead.
> - Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).

## Storefront Checkout Started

Fires when a shopper enters checkout - at the start, not when they abandon it.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Storefront Behaviour Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- Measure checkout starts against orders.
- Notice very large checkouts while they happen.

### What Storefront Checkout Started sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `checkoutSnapshot` | Object | The checkout token, line count and total |
| `checkoutSnapshot.checkoutToken` | Text |  |
| `checkoutSnapshot.lineItemCount` | Number |  |
| `checkoutSnapshot.total` | Money (amount, currencyCode) |  |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: Alert on a large checkout

1. Pick **Storefront Checkout Started** as the trigger.
2. Add a **Condition**: `checkoutSnapshot.lineItemCount` **Greater than** `15`.
3. Add **Send internal email** with `{{checkoutSnapshot.total.amount}} {{checkoutSnapshot.total.currencyCode}}`.
4. Turn the workflow on.

> [!NOTE]
> **Good to know**
> - Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).
> - For recovering abandoned checkouts use Shopify's own **Customer abandons checkout** trigger, which knows the customer. This one does not.

## Storefront Search

Fires when a storefront search returns **at least one** result. It carries the term, the number of results, up to ten matches, and the first match as a product reference.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Storefront Behaviour Access** + **Product, Variant & Collection Data Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- See what shoppers search for and what they are shown first.
- Check that important terms lead to the right product.

### What Storefront Search sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `product` | Product (Shopify) | The first product the search returned, as a full product you can branch on. A full Shopify product, so all of its fields and Flow's own product actions are available. |
| `storefrontSearch` | Object | The search term, the number of results, and up to 10 matches including the first |
| `storefrontSearch.query` | Text | The term the shopper typed. |
| `storefrontSearch.resultCount` | Number | How many product variants the search returned. |
| `storefrontSearch.results` | List of objects | The matches, newest-relevance first, capped at 10 to keep the payload small. |
| `storefrontSearch.results (each).productId` | ID |  |
| `storefrontSearch.results (each).title` | Text |  |
| `storefrontSearch.results (each).vendor` | Text |  |
| `storefrontSearch.results (each).url` | Text |  |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: Check what a key search term shows first

1. Pick **Storefront Search** as the trigger.
2. Add a **Condition**: `storefrontSearch.query` **Includes** `gift card`.
3. Add a second **Condition**: `product.title` **Does not include** `Gift Card`, then **Send internal email**: the first hit for `{{storefrontSearch.query}}` was `{{product.title}}`.
4. Turn the workflow on.

> [!NOTE]
> **Good to know**
> - Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).
> - A single search fires either this trigger or the no-results one, never both.

## Storefront Search Returned No Results

Fires when a storefront search finds **nothing**. This is a list of things shoppers expected you to sell, or words your search does not understand.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Storefront Behaviour Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- Collect missing products and synonyms.
- Spot a broken search after a theme or app change: a sudden rise is a symptom.

### What Storefront Search Returned No Results sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `searchQuery` | Object | The search term and its result count |
| `searchQuery.query` | Text |  |
| `searchQuery.resultCount` | Number |  |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: Collect searches without results in a sheet

1. Pick **Storefront Search Returned No Results** as the trigger.
2. Add **Send HTTP request** to a Google Sheets or Airtable webhook with `{{searchQuery.query}}`.
3. Review the sheet weekly: add synonyms or redirects in Shopify's Search & Discovery app, or stock what people ask for.
4. Turn the workflow on.

> [!NOTE]
> **Good to know**
> - Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).
> - Search terms are typed by shoppers and can contain anything, including personal data. Do not forward them to places more public than they need to be.

## Out-of-Stock Variant Viewed

Fires when a shopper lands on a product page whose **shown variant** is sold out across all locations. It is a demand signal: someone wanted something you could not sell.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Storefront Behaviour Access** + **Inventory Data Access** + **Product, Variant & Collection Data Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- Prioritise restocks by real demand.
- Tag products for a back-in-stock campaign.

### What Out-of-Stock Variant Viewed sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `product` | Product (Shopify) | The product the out-of-stock variant belongs to. A full Shopify product, so all of its fields and Flow's own product actions are available. |
| `outOfStockVariant` | Object | The variant and its available quantity |
| `outOfStockVariant.variantId` | ID |  |
| `outOfStockVariant.variantTitle` | Text |  |
| `outOfStockVariant.sku` | Text |  |
| `outOfStockVariant.availableQuantity` | Number |  |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: Tag sold-out products that shoppers still look at

1. Pick **Out-of-Stock Variant Viewed** as the trigger.
2. Add **Add product tags** with `restock-demand`.
3. Add **Send internal email** to buying: `{{product.title}} / {{outOfStockVariant.variantTitle}} ({{outOfStockVariant.sku}}) was viewed while sold out`.
4. Turn the workflow on.

> [!NOTE]
> **Good to know**
> - It is derived from product views, so switching it on also switches **Storefront Product Viewed** on, and every product view counts towards your plan.
> - Only the variant shown when the page loads is checked. Picking a sold-out variant afterwards is not a new page view and is not seen.
> - Needs **Inventory** and **Product Data Access** next to Storefront Behaviour Access.
> - Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).

## Signed-In Customer Visited

Fires when a **signed-in** customer is on your storefront. Repeated page views are collapsed into one visit per customer within a window you choose, from every visit to once a month.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Storefront Behaviour Access** + **Customer Data Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- Tell an account manager that a key customer is back.
- Start a re-engagement step for customers who return after a long time.

### What Signed-In Customer Visited sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `customer` | Customer (Shopify) | The signed-in customer, with their full record for branching. A full Shopify customer, so all of its fields and Flow's own customer actions are available. |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: Tell the account manager that a VIP is browsing

1. In the app open the settings icon next to **Signed-In Customer Visited** and choose the visit window, for example once a day.
2. Pick **Signed-In Customer Visited** in Flow.
3. Add a **Condition**: `customer.tags` **Includes** `vip`.
4. Add **Send internal email** with `{{customer.displayName}}`.
5. Turn the workflow on.

> [!NOTE]
> **Good to know**
> - Needs **Customer Data Access**, because the customer arrives as a reference.
> - Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).

## B2B Buyer Visited

Fires when a signed-in **B2B buyer** is on your storefront, with the company and the company location they buy for. Visits are collapsed per **company** within the window you choose.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Company & Company Location Data Access (B2B)** + **Storefront Behaviour Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- Alert the sales rep of a company when its buyers are active.
- Measure how often wholesale accounts come back.

### What B2B Buyer Visited sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `purchasingCompany` | Object | The company and location the buyer purchases for |
| `purchasingCompany.companyId` | ID |  |
| `purchasingCompany.companyName` | Text |  |
| `purchasingCompany.companyLocationId` | ID |  |
| `purchasingCompany.companyLocationName` | Text |  |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: Alert the rep when a company's buyer is active

1. Set the visit window with the settings icon next to **B2B Buyer Visited** in the app.
2. Pick **B2B Buyer Visited** in Flow.
3. Add **Send internal email**: `A buyer of {{purchasingCompany.companyName}} ({{purchasingCompany.companyLocationName}}) is on the store`.
4. Turn the workflow on.

> [!NOTE]
> **Good to know**
> - Two buyers of the same company inside one window count as one visit.
> - Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).

## Custom Storefront Trigger

Fires when your **theme** publishes an event you defined: a cart drawer opening, a size guide being used, a quiz being finished. You create the trigger in the app, give it an event name, and publish that name from your theme with one line of JavaScript.

| | |
| --- | --- |
| **Fires from** | The app's storefront pixel, in the shopper's browser |
| **Permission** | **Storefront Behaviour Access** |
| **Switched on** | Turning on a Flow workflow that uses it switches it on. Its own switch is on the app's **Triggers** page |

**Use it for**

- Everything Shopify does not report: drawers, modals, variant switches, configurators.
- Pass your own data along and use it in Flow.

### What Custom Storefront Trigger sends to your workflow

| Variable in Flow | Type | What it holds |
| --- | --- | --- |
| `eventName` | Text | The event name you published, e.g. cart_drawer_opened. Filter on this to run only for one of them. |
| `triggerName` | Text | The name you gave this storefront trigger. |
| `output` | Object | The data you published with the event, after your transform code ran. |
| `output.fields` | List of objects | Each key, in the order it was defined. |
| `output.fields (each).key` | Text | The key, exactly as published or returned by the transform (e.g. "itemCount"). |
| `output.fields (each).value` | Text | The value, stringified. Objects and arrays arrive as JSON text. |
| `output.json` | Text | The whole payload as JSON, for merchants who prefer to parse it in one go. |
| `eventId` | Text | The id of this event. Search for it in the app's Event History to see exactly what was sent. |

### Example: React to a finished product quiz

1. In the app open **Triggers**, create a **Custom Storefront Trigger** and give it the event name `quiz_completed`. Copy the snippet it shows.
2. In your theme, call the snippet when the quiz finishes and pass the result, for example `{ result: "dry-skin" }`.
3. In Flow pick **Custom Storefront Trigger** and add a **Condition**: `eventName` **Equal to** `quiz_completed`.
4. Read your data from `output.fields` (key and value pairs) or parse `output.json` in a **Run code** step.
5. Turn the workflow on.

> [!NOTE]
> **Good to know**
> - Every Custom Storefront Trigger arrives in Flow as the same trigger, so **always** start with a condition on `eventName`.
> - What you publish is under your control, and so is the responsibility: do not publish personal data. Full guide: [Custom Storefront Triggers](https://docs.workflow-trigger-extensions.app/custom-storefront-triggers.md).
> - Collected in the shopper's browser and only with analytics consent, so it under-reports by design and can miss events (ad blockers, closed tabs). Use it for signals, never where a missed event would be a correctness problem. See [Storefront triggers](https://docs.workflow-trigger-extensions.app/storefront-triggers.md).

## Next steps

All of them need **Storefront Behaviour Access**. The ones that carry a product also need Product Data Access, Signed-In Customer Visited also needs Customer Data Access, and B2B Buyer Visited also needs Company access.

- [Complete trigger reference](https://docs.workflow-trigger-extensions.app/trigger-reference.md) - every trigger on one page.
- [Choosing the right trigger](https://docs.workflow-trigger-extensions.app/choosing-the-right-trigger.md) - which one fits your case.
- [Custom triggers](https://docs.workflow-trigger-extensions.app/custom-triggers.md) - when no built-in trigger fits, write your own.
- [Event history and troubleshooting](https://docs.workflow-trigger-extensions.app/event-history-and-troubleshooting.md) - see what fired and what it carried.