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 | A viewed product was neither carted nor checked out for 2 hours | 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 and the order date. 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 or order date, 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.
- 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.
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.
{{rv_checkout_url}}is Shopify's own recovery link: opening it restores the cart and resumes the checkout. - 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. - Product browsed, not bought — a product viewed but neither added to the cart nor taken to checkout for a quiet period of 2 hours. Views under about ten seconds do not count. It carries the product, the variant, the price, the product page and the image URL. 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 already name: someone who arrived from a link IcloneU sent them, or who is logged into their store account and matches an existing contact by email. 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 only fires once — a checkout that has already fired is never swept again.
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.
Two ready-made commerce flows
You do not have to build these from scratch. Automations → Gallery carries two recipes under Sales, both marked as needing the Shopify connector. Installing one fills in its blanks and lands the flow as a Draft you review and set Live yourself.
- 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 Checkout abandoned. It installs three wired pieces at once: the 1 hour / 1 day / 3 days recovery sequence, the Shopify entry flow that enrols the buyer, 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.
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. The second recovery message inside a day is skipped, not delayed.
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.
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. Revenue sums order totals as recorded, so a store selling in several currencies sees a blended figure. The section reads purchase amounts, so a team member without the contacts permission does not see it at all.
Frequently asked
Not from the product. They are platform defaults — 60 minutes for an abandoned checkout, 60 minutes for an abandoned cart, 2 hours for a browsed product, plus a roughly ten-second minimum on a product view. 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 who arrived from a link IcloneU sent, or who is logged into their store account and matches a contact by email. 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 two things in order. A recipe installs as a Draft, so it does nothing until you set it Live. 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: an abandoned cart is swept once, and 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 August 25, 2026 · Platform Integrations
