> ## Documentation Index
> Fetch the complete documentation index at: https://docs.digifist.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Triggers
> The nine automation triggers available in Galantis — the Shopify and platform events that start a flow.
A trigger is the entry point of every automation. It defines the event that enrolls a customer into the flow. When that event fires for a qualifying customer, Galantis starts executing the flow from the `TriggerNode` for that customer — independently of any other customer's execution.
Every automation has exactly one trigger. Choosing the right trigger is the most consequential decision in flow design — it determines which customer behavior the automation responds to and when the first message can reach the customer.
## What this covers
* All nine available triggers with their source and description
* The `include_existing_users` option
* Trigger-specific notes and timing considerations
## Available triggers
### Order Placed
**Trigger:** `ORDER_PLACED`
**Source:** Shopify — fires when a new order is created via the `orders/create` webhook.
Fires immediately when a customer completes a purchase. The triggering order's data (order number, total price, product names, tags) is available in condition nodes and action variable mapping for this flow.
Common uses: order confirmation messages, post-purchase cross-sell sequences, review request flows.
Galantis receives this trigger via Shopify's `orders/create` webhook — it fires on every new order, including orders placed through all sales channels connected to your Shopify store, not only your online storefront.
***
### Order Cancelled
**Trigger:** `ORDER_CANCELLED`
**Source:** Shopify — fires via the `orders/cancelled` webhook.
Fires when an order is cancelled in Shopify, regardless of who initiated the cancellation. Use with a `CUSTOMER_TAG` or `ORDER_VALUE` condition to segment your response — for example, sending a win-back offer to high-value cancelled orders while sending a simpler acknowledgment to lower-value ones.
***
### Order Shipped
**Trigger:** `ORDER_SHIPPED`
**Source:** Shopify — fires when a fulfillment is created via the `orders/updated` webhook with shipping data.
Fires when an order is marked as fulfilled and a tracking number is available. Use for shipping confirmation messages and delivery update flows.
### New Customer Created
**Trigger:** `CUSTOMER_CREATED`
**Source:** Shopify — fires via the `customers/create` webhook.
Fires when a new customer record is created in Shopify — typically at the point of first purchase or account registration. This is the standard entry point for welcome sequences.
Add a delay of 10–15 minutes after this trigger before the first action. New customers typically receive a Shopify registration or order confirmation email almost immediately — a short delay prevents your WhatsApp message from arriving in the same moment and reduces the sense of automated messaging.
***
### Customer Tagged
**Trigger:** `CUSTOMER_TAGGED`
**Source:** Shopify — fires via `customer_tags/added` webhook when a specific tag is added to a customer record.
Fires when a defined tag is applied to a customer in Shopify, either manually or through a Shopify Flow or third-party app. Useful for lifecycle-based triggers — VIP promotion, loyalty tier upgrades, or any workflow where a Shopify tag signals a status change.
Configuration requires specifying the exact tag string to listen for. Only the defined tag fires this trigger — other tags added to the same customer do not.
### Abandoned Checkout
**Trigger:** `ABANDONED_CHECKOUT`
**Source:** Shopify — polled every 10 minutes via the Shopify Admin API.
Fires when a customer starts a checkout but does not complete it. Because Shopify does not emit a real-time webhook for abandoned checkouts, Galantis polls for them on a 10-minute interval. This means the trigger fires at most 10 minutes after abandonment occurs, not instantly.
This is typically the highest-ROI automation trigger available — abandoned checkout recovery consistently drives significant recovered revenue.
The 10-minute polling interval means there is an inherent delay between the moment a customer abandons and when the trigger fires. Account for this when configuring your first delay node — a 30-minute delay after the trigger results in the customer receiving the message approximately 30–40 minutes after abandonment, not exactly 30 minutes.
### User Added to List
**Trigger:** `USER_ADDED_TO_LIST`
**Source:** Galantis — fires when a customer is added to a specific Customer List.
Fires when a customer is manually added to a defined list, imported into it, or added programmatically. Useful for triggering flows based on internal list management — for example, a flow that fires when a customer is added to a "VIP" or "Re-engagement" list.
Configuration requires specifying which list to listen for. Adding a customer to a different list does not fire this trigger.
***
### User Added to Segment
**Trigger:** `USER_ADDED_TO_SEGMENT`
**Source:** Galantis — fires when a customer newly matches a segment's rules and is added to segment membership.
Fires when segment evaluation runs and a customer moves from non-member to member status for the defined segment. This trigger does not fire for customers who were already members when the automation was activated — it fires only on the transition into membership.
This is particularly powerful for lifecycle-based automation — for example, a flow that fires when a customer crosses into a "High LTV - Lapsed" segment for the first time.
***
### Back in Stock
**Trigger:** `BACK_IN_STOCK`
**Source:** Galantis — fires when a subscribed product variant's inventory changes from `0` to a positive quantity.
Fires when Galantis detects a restock event for a variant that has active subscribers. This trigger is the engine behind the Back-in-Stock notification module. See [Back-in-Stock — Notification Logic](/whatsapp/back-in-stock/notification-logic) for how the restock detection pipeline works.
## Trigger reference
| Trigger | Source | Event |
| ----------------------- | -------- | ----------------------------------------------------- |
| `ORDER_PLACED` | Shopify | New order created |
| `ORDER_CANCELLED` | Shopify | Order cancelled |
| `ORDER_SHIPPED` | Shopify | Order fulfilled/shipped |
| `CUSTOMER_CREATED` | Shopify | New customer registered |
| `CUSTOMER_TAGGED` | Shopify | Specific tag added to customer |
| `ABANDONED_CHECKOUT` | Shopify | Checkout started, not completed (polled every 10 min) |
| `USER_ADDED_TO_LIST` | Galantis | Customer added to a specific list |
| `USER_ADDED_TO_SEGMENT` | Galantis | Customer newly matches a segment's rules |
| `BACK_IN_STOCK` | Galantis | Subscribed variant restocked |
## Include existing users
Every trigger supports an `include_existing_users` option. When enabled at the time of activation, Galantis retroactively enrolls customers who already match the trigger condition — for example, customers who abandoned a checkout before the automation was active, or customers already in a segment when the segment trigger is configured.
When disabled (default), only events that occur after the automation is activated will enroll customers.
Use `include_existing_users` carefully for high-volume triggers like `ORDER_PLACED` or `CUSTOMER_CREATED`. Enabling it on a large existing customer base can generate a significant immediate send volume. Review your frequency caps and credit balance before activating with this option enabled.
## Related guides
* [Flow Builder](./flow-builder) — Building and connecting nodes on the canvas
* [Conditions](./conditions) — Branching logic based on trigger event data
* [Frequency Caps](./frequency-caps) — Controlling how often a trigger can fire per customer
* [Recipes](./recipes/index) — Pre-built flows showing trigger configuration in context