Connecting your store gives your clone the catalogue. It also gives Automations a set of triggers: seven store events that start a workflow on their own, with nobody having to message you first. An order arriving, a parcel moving, a checkout going quiet — each one can start a flow that tags the contact, sends a WhatsApp message, or enrols them in a sequence.
These triggers only exist once a Shopify store is connected under Automations → Connectors — see Connecting your Shopify store. Two of the three recovery events also need the browse pixel; that is a separate paste-in step covered in Adding the browse pixel to your Shopify store.
The seven store events
These are the names as they appear in the trigger picker, grouped under Shopify. Four of them describe an order that exists. Three describe a purchase that did not happen, and those three are treated differently by the platform — see the guardrails below.
| Event | Fires when | Class |
|---|---|---|
| Order created | An order is placed, before payment | Transactional |
| Order paid | The order is paid | Transactional |
| Order fulfilled | The store marks the order fulfilled | Transactional |
| Order shipment update | The carrier reports progress on a shipped order | Transactional |
| Checkout abandoned | A started checkout produced no order for 60 minutes | Recovery |
| Cart abandoned | A cart never reached checkout for 60 minutes | Recovery |
| Product browsed, not bought | Products a shopper viewed were neither carted nor checked out, 2 hours after their last view | Recovery |
Checkout abandoned, Cart abandoned and Product browsed, not bought are flagged as marketing in the connector itself, so every message they send passes through opt-out, handover and frequency checks. The four order events are transactional and bypass all three. That difference is the single most common reason a recovery message you expected never arrived.
The four order events
All four come from Shopify's own order notifications, so they arrive within seconds and need no pixel. Order created, Order paid and Order fulfilled each carry the buyer (email, phone, first and last name), the order reference and id, the products, the total, the currency, the order date and the link to the order's status page in your store ({{rv_order_status_url}}). Order shipment update is the exception: it carries the buyer, the order reference and id and the products, plus the carrier, tracking number, tracking URL, estimated delivery and the shipment status itself — but no total, currency, order date or status-page link, because it describes a parcel rather than a purchase. All of them arrive as {{rv_*}} variables you can drop into any later step.
- Order created — fires the moment the order is placed, before payment. On top of the common fields it carries
{{rv_payment_method}}(the raw gateway name),{{rv_financial_status}}(typicallypendingon an unpaid order) and{{rv_is_cod}}. This is the entry point for a cash-on-delivery confirmation, where you ask the buyer to confirm before you ship. - Order paid — the earliest confirmed-purchase signal, before fulfilment. It is also the event that writes the order onto the buyer's contact, so purchase history and lifetime totals stay current without you importing anything. Recording is keyed on the order reference, so a redelivery from Shopify never double-counts.
- Order fulfilled — fires when the store marks the order fulfilled. It is the only event that schedules an automatic review request, which is why a paid-but-unshipped order books nothing. It also carries the tracking details on the fulfilment —
{{rv_tracking_company}},{{rv_tracking_number}}and{{rv_tracking_url}}, empty when the order was fulfilled without tracking — so a flow can send the tracking number the moment the order ships. - Order shipment update — fires on carrier progress for a shipped order.
{{rv_shipment_status}}carries the state —confirmed,in_transit,out_for_delivery,delivered,attempted_delivery,failure, plus label and pickup states — alongside{{rv_tracking_company}},{{rv_tracking_number}},{{rv_tracking_url}}and{{rv_estimated_delivery}}. It only fires when Shopify can actually track the carrier, the estimated delivery is carrier-provided and often empty, and repeated notifications of the same status collapse into one event so a flow does not message twice about the same step. It also needs the shipment-tracking scopes on your Shopify app (see Connecting your Shopify store, Step 2): without them Shopify refuses IcloneU's subscription to these updates and the trigger never fires. For most messages Order fulfilled is the better trigger anyway — it fires when you mark the order fulfilled and already carries the tracking number. The automatic subscription is only for a Client ID and Secret connection: a legacyshpat_connection gets none, so each event it needs is a webhook you create by hand in Shopify, as in Step 5 of that guide — here, Fulfillment update.
Shopify has no COD field. {{rv_is_cod}} is true when the gateway name is Shopify's own Cash on Delivery (COD), or the Mexican renames contra entrega / contraentrega. A store on a fully custom manual gateway will not match, and the flow should branch on {{rv_payment_method}} instead.
{{rv_item_name}} is only the highest-priced line on the order. {{rv_item_names}} is the full list. A message that says “your {{rv_item_name}} is on its way” is correct for a single-item order and quietly wrong for a basket of four.
The three recovery events
These are derived, not delivered. Shopify has no abandonment notification, so IcloneU watches for the silence itself: it holds the started checkout, the cart or the product view, and fires only once a quiet period passes with nothing happening. The quiet windows are platform defaults and there is no setting for them in the product.
- Checkout abandoned — a started checkout that produced no order for a quiet period of 60 minutes. It only fires when the checkout captured an email or a phone number, because without one there is nobody to reach, and when Shopify also sent the checkout's recovery link.
{{rv_checkout_url}}is that link, Shopify's own: opening it restores the cart and resumes the checkout. A checkout Shopify sends without the link waits instead of being dropped, and can still fire if a later update from Shopify brings the link. - Cart abandoned — products added to the cart that never reached checkout for a quiet period of 60 minutes. One event covers the whole cart, not one per line.
{{rv_cart_url}}is a Shopify cart permalink that rebuilds the cart when clicked, so it works from a different device with no session behind it, and Shopify re-checks stock at that moment. If the shopper paid for any order in the 24 hours before first adding a product, or at any time since, or for that same product in the 14 days before, that product is left out of the event and its link, and a cart with nothing else in it gets no event. Each variant (a product in one size or colour) keeps the date it was first added to the cart, so one that was already in the cart before an order, or was first added in the 24 hours after it, stays out whenever it's added again, for at least 30 days after it was last added. - Product browsed, not bought — products viewed but neither added to the cart nor taken to checkout. It fires once per visit, when 2 hours have passed since the shopper's last product view in your store: every further view restarts the clock, even a quick one, and at least one view has to last about ten seconds. Views shorter than that are left out of the event. It carries one product — the one they opened most recently among those they looked at for about ten seconds or more — with its variant, price, product page and image URL, plus
{{rv_product_names}}, every product of the visit that passed the ten seconds, that one first, and{{rv_product_count}}, how many there were. A shopper who paid for any order in the 24 hours before the view, or for that same product in the 14 days before, gets no event. Worth adding a Condition on a Check Sizes & Store Availability action before the message, so the flow suppresses itself when the product has since sold out.
Cart abandoned and Product browsed, not bought both need the browse pixel, and both only track visitors IcloneU can name: someone whose browser once opened a store link that identifies them (the product and checkout links your Clone sends, or the product, cart and checkout links a store event hands to a flow), who is logged into their store account and matches an existing contact by email, or who signs up through one of your capture forms or, with the optional Klaviyo forms bridge, a Klaviyo sign-up form. Anonymous browsing is never recorded. A test in a private window produces nothing, and that is the design, not a fault. Checkout abandoned is different — it comes from the store's checkout notifications, so it needs no pixel.
Reaching checkout hands the story over to Checkout abandoned, so only one of the two fires per purchase attempt. Build them as one recovery path rather than two competing ones, and remember an event can fire again for the same shopper: a checkout fires again only if the shopper comes back to it after 24 quiet hours, a cart with every new add, and a browse event with every new visit. So what keeps a returning shopper from a second round of reminders is the sequence (nobody is enrolled twice at once, and a shopper who finished re-enters only once its cooldown has passed) or your own flow's logic.
When Shopify reports an order paid, IcloneU closes everything still waiting to fire for that shopper — their cart, the products they browsed and their open checkouts — so none of it fires after the purchase. Each check also looks for a purchase once more just before it fires. A checkout the shopper starts after buying counts as new straight away and can fire as usual. Their cart and browsing count as new only from 24 hours after the purchase (14 days for the product they bought): from then on, a product added to the cart can fire again, and so can browsing — except a variant that was already in their cart before the purchase, or was first added in the 24 hours after it, bought or not, which stays quiet when it's added again, for at least 30 days after it was last added. A drip that had already started stops through its purchase tag, which the Gallery recipes' Purchased tag flow applies.
Setting one up
Open the flow
Go to Automations → Workflows and create a new automation, or open an existing one.
Add a Connector event trigger
Add a trigger and pick Connector event. Its own description reads: “Runs this workflow every time the selected platform event arrives through the connector. The event's data is available as variables in the nodes below.”
Pick the Event
The Event dropdown groups events under each connected platform, so the list depends on what you have connected. If you have more than one Shopify connection the name gains (all connections) — matching is per account, so the event from any of your stores starts the same flow.
Read the variables
Once an event is selected, a View available variables button appears. It lists that event's fields with their
{{rv_*}}tokens, ready to paste into a message, a condition or a tag.Assign the platform account, then set it Live
Build the rest of the flow, make sure the automation has a platform account assigned, and click Set Live. A Draft never fires — and neither does a Live flow with no platform account, which is the quietest way to lose a store automation.
A flow can carry a store event whose connector has no connection on this account — an installed recipe, an imported flow, a store connected on a sibling account, a connection since removed. IcloneU now says so instead of letting you wait: the editor shows “This flow is triggered by a connector event, but that connector is not connected on this account — the trigger will never fire.” with a Go to Connectors link, and the trigger card carries a warning triangle reading “This connector is not connected on this account — the trigger will never fire.” Saving is still allowed and the event you picked stays selected, so you can connect the store and come back. The connection list is read once when the editor opens, so after connecting, reopen the flow for the warning to clear.
Four ready-made commerce flows
You do not have to build these from scratch. Automations → Gallery carries four recipes under Sales, and all four listen to Shopify events, so they need the Shopify connector. Installing one fills in its blanks and lands the flow as a Draft you review and set Live yourself. The three recovery recipes each install the same companion tag flow: if you install more than one, keep a single copy Live. The details are in Automation recipes.
- COD order confirmation — triggered by Order created. It checks whether the order is cash on delivery, asks the buyer to confirm before you ship, and tags them while you wait. The one blank it asks for is Tag while awaiting confirmation, which defaults to
cod-pending. - Abandoned cart recovery — triggered by Cart abandoned, so it needs the browse pixel as well. It installs three wired pieces at once: the 1 hour / 1 day / 3 days recovery sequence, the entry flow that enrols the shopper, and a companion flow on Order paid that tags the purchase so the reminders stop the moment they buy. That last piece is the one most hand-built cart flows forget, and its absence is what keeps messaging people who already paid.
- Abandoned checkout recovery — triggered by Checkout abandoned, with no pixel needed: the checkout itself carries the shopper's contact details and the link to resume it. The same three pieces and the same 1 hour / 1 day / 3 days ladder.
- Browse abandonment nudge — triggered by Product browsed, not bought, so it needs the browse pixel. Two gentle reminders, 2 hours and then 2 days later; the second names the product and links back to it. The same three pieces.
What holds a recovery message back
The three recovery events are marketing messages, and IcloneU rations them on your behalf. A flow that looks correct and still sends nothing is usually meeting one of these three rules rather than failing.
- Opt-out. A contact who opted out never receives a recovery message, even when the abandoned cart is older than the opt-out. The suppression happens before the frequency count, so it does not burn one of their slots either.
- An open handover. While a conversation sits in an open handover, the recovery message for that event is dropped rather than queued — it never arrives late. See Reply timing and handover settings for exactly which automated messages wait and which are dropped.
- A frequency cap. Across all of your flows together — recovery flows, sequence steps and broadcasts share the same ledger — a contact is touched at most once in 24 hours and three times in 7 days. A recovery message sent straight from a flow is skipped when the cap blocks it, not delayed; a sequence step — which is how the three Gallery recovery recipes send — is postponed by about a day instead.
Order created, Order paid, Order fulfilled and Order shipment update are transactional. They ignore all three rules, because a customer who opted out of marketing has not opted out of being told their parcel shipped. That is also why a COD confirmation flow keeps working for a contact your cart-recovery flow is not allowed to touch.
One marketing touch per 24 hours means your second test message to your own contact silently does not arrive. Test with a different contact, or wait, before you conclude the flow is broken.
A store event names the shopper by email, phone or both, but a flow on a WhatsApp account can only message a phone number: the contact's WhatsApp number, else a phone on file, else the phone the event carried. With none of them — say, a checkout that captured only an email, from a shopper with no phone on file — the flow still applies its tags and fields, but its WhatsApp messages are skipped and nobody is enrolled in its sequence. So those shoppers never enter a WhatsApp recovery drip such as the Gallery's, and the drip's enrolments can trail your abandoned checkouts. The four order events follow the same rule.
Automatic review requests ride on Order fulfilled
The one commerce automation you do not build as a workflow is the post-purchase review request. It is configured in Reviews → Settings, under Getting more reviews, and it listens to exactly one store event.
- Only Order fulfilled schedules a request. When the store marks an order fulfilled and Send review requests automatically after a purchase is on, IcloneU books the request for Days after purchase from now. Marking an order paid books nothing.
- Configure the WhatsApp card first. The WhatsApp review requests card is a separate card from Automatic review requests, and the WhatsApp option only appears in the automatic card's Channel picker once the WhatsApp card has a WhatsApp number, a Template and a Review link variable chosen. Until then the only channel offered is Email.
- Map the product variable too. Product/item variable (optional) is what carries the purchased product's name into the template. A purchase-triggered request that does not name what they bought loses most of its point.
- Five things stop a request from sending. The same contact was already asked in the last 90 days; the contact opted out; the chosen channel is not configured; there is no usable phone or email on file; or WhatsApp has already told us that number is not on WhatsApp. Each of those lands the request as skipped rather than sent.
- An open handover postpones rather than drops. Unlike a recovery message, a review request for a contact with an open handover is pushed back an hour and retried, so it goes out once the case closes.
Turning automatic requests on displays the line “Automatic sending activates once a purchase source (e.g. Shopify order sync) is connected. Your settings are saved and ready.” It is shown unconditionally, including on accounts whose Shopify store is connected and whose requests are already going out. If your store is connected, ignore it and check Reviews → Requests for the real answer.
Checking that it works
Two surfaces answer the two different questions — did the event reach us, and did the messages we sent earn anything.
- Did the event arrive? Open Automations → Connectors, edit the Shopify connection and look at Recent events — the last ten, with a status each. Processed means something acted on it, Ignored means nothing matched it, Failed means it errored, and Received means it was logged but never stamped with an outcome. An Ignored event you expected a flow to catch means the flow is not eligible: still a Draft, or Live with no platform account assigned. If the list reads “No events received from this connection yet.”, the problem is upstream of your workflow entirely. Payloads are never shown here — customer data stays out of the log.
- Did it earn anything? The Recovery performance section of your Dashboard shows one row per recovery flow with Messages, Contacts, Purchases and Revenue over 7, 15 or 30 days. A purchase counts against a flow when that flow was the last marketing touch within 7 days, so read it as attribution, not as a full-funnel revenue report. When anything in the period is credited, the card opens with Influenced sales, which adds the purchases your clone helped along in conversations and counts a purchase reached both ways once. Revenue sums order totals as recorded, so a store selling in several currencies sees a blended figure.
Frequently asked
Not from the product. They are platform defaults — 60 minutes for an abandoned checkout, 60 minutes for an abandoned cart, 2 hours after the shopper's last product view for browsing, plus a roughly ten-second minimum on at least one of those views. What you can change is what happens after the event: put a Wait node at the top of the flow to stretch the delay, never to shorten it.
Almost always the pixel or the visitor. Cart abandoned needs the browse pixel installed in the store, and it only records visitors IcloneU can identify — someone whose browser once opened a store link that identifies them (the product and checkout links your Clone sends, or the product, cart and checkout links a store event hands to a flow), who is logged into their store account and matches a contact by email, or who signed up through one of your capture forms or, with the Klaviyo forms bridge, a Klaviyo form. Checkout abandoned needs neither, because it comes from the store's checkout notifications. If your own test was in a private window, nothing was recorded to abandon.
Check four things in order. A recipe installs as a Draft, so it does nothing until you set it Live. Its flows install with no connected account: pick one in each, the Purchased-tag flow included, because a Live store-event flow with no account is skipped. On the three recovery recipes, open the sequence on the Sequences tab, pick a sending WhatsApp account on every step (Set platform) and choose the approved template for step 1: a step with no account ends the drip without sending anything. And if the store is not connected on this account, the editor shows a warning strip above the canvas with a Go to Connectors link — the trigger will never fire until that connection exists. Connect the store, then reopen the flow, since the editor reads the connection list once when it opens.
No. These events fire forward only: a cart that went quiet before the flow existed is never revisited. The recovery flows recover from the moment they go Live, not retrospectively.
Yes — the recovery message opens a normal conversation on that channel, and your clone handles the reply like any other. That is worth planning for: an abandoned-cart nudge that works often ends in a question about sizes or shipping, so the clone answering it should have the store connection switched on in its Skills tab.
Last updated September 23, 2026 · Platform Integrations
