What triggers a workflow (and what doesn't)

Every workflow starts with a trigger. Most triggers are Shopify webhooks: Shopify tells Arigato that something happened, and the workflow runs on that object. A few others are Arigato's own: schedules, bulk operations, on-demand runs, POS, and incoming HTTP requests.

Not every change in Shopify sends a webhook. The second half of this article lists the things people expect to be triggers that aren't, and what to use instead.

Ways a workflow can start

Start step When it runs Notes
When [something happens] Shopify sends a webhook The full list is below. This is most workflows.
Run on a schedule Hourly, daily, weekly, monthly Unlimited plan. See Scheduled Workflows.
Run in a bulk operation Once, over every matching item Unlimited plan. See Bulk Operation Workflows.
Run on-demand When you pick items in the Shopify admin See On-Demand Workflows.
Triggered from POS When staff run it from Shopify POS Manual only. It never runs in the background. To handle POS orders automatically, use When an order is created with a condition on the sales channel.
HTTP Request When something calls the workflow's URL For forms, other apps, Zapier. See Custom Workflows.
Triggered by parent workflow From a Loop or subworkflow step Not chosen directly. See Loops.

Available on schedule, bulk and on-demand: orders, draft orders, products, product variants, customers, collections, disputes (schedule and bulk only), companies (on-demand only).

Event triggers, by object

Object Triggers
Order created · updated · paid · fulfilled · partially fulfilled · cancelled · deleted · edited
Draft order created · updated
Checkout created · updated
Order transaction created
Refund created
Return requested · approved · declined · updated · reopened · closed · cancelled
Dispute created · updated
Fulfillment created · updated
Fulfillment shipping event created (tracking updates from the carrier)
Fulfillment order placed on hold · hold released · moved · rescheduled · cancelled · order routing complete · scheduled fulfillment order ready · fulfillment request submitted / accepted / rejected · cancellation request submitted / accepted / rejected · fulfillment service failed to complete · line items prepared for pickup · line items prepared for local delivery
Product created · updated or sold · deleted
Product variant becomes in stock · becomes out of stock
Inventory item created · updated
Inventory level updated (any quantity change at a location)
Collection created · updated · deleted
Customer created · updated · deleted · tags added · tags removed
Company (B2B) created · updated · deleted
Metaobject created · updated · deleted

Things that are not triggers, and what to use instead

A metafield changed. Shopify has no metafield webhook. Editing a product metafield fires When a product is updated, but the webhook doesn't say what changed. To act only on a change, store the last value in the Arigato Database and compare on each run. Variant metafield edits don't reliably fire anything. Metaobjects are the exception: they have their own created, updated and deleted triggers.

A variant or SKU was added. There's no variant-created trigger. Every new variant gets an inventory item, so When an inventory item is created is the closest, and inventory_item.variant gives you the variant. Test it on your store before relying on it.

Inventory quantity changed. Don't use When a product is updated for this. Use When an inventory level is updated for any quantity change at a location, or When a product variant becomes in stock / out of stock for the two cases most workflows care about. These are faster and don't need the extra inventory lookups that slow down product workflows.

Payment terms or due date changed. No webhook. When an order is updated fires for many reasons and the due date in the payload can be stale.

A discount code was created, or a gift card was issued. No webhook for either.

A review was posted, a form was submitted, an email arrived, someone posted in Slack, another app did something. None of these are Shopify events. Options, in order of preference:

  1. If the other app can call a URL, use an HTTP Request workflow and paste its URL into the app's webhook setting.
  2. If the app stores its data in metaobjects, use the metaobject triggers.
  3. If the app tags the customer, use When tags are added to a customer.
  4. Otherwise a bridge like Zapier can turn an email into a call to your HTTP Request workflow.

A return was started in a returns app. Return triggers only fire when the return exists in Shopify. Returns handled entirely inside a third-party app (Loop and similar) don't reach Arigato unless that app registers them with Shopify.

A payment on a draft order. When an order transaction is created fires for orders, not draft orders.

Items added to an order after it was placed. A workflow that ran on When an order is created won't see upsells or edits made later. Use When an order is edited for those.

An abandoned checkout. When a checkout is created fires when the checkout starts, before Shopify considers it abandoned. Add a Wait step (45 minutes is a safe margin) and then check the checkout's status before emailing.

Created or updated?

  • When an order is updated also fires when the order is created, and again for every later change, including cancellation. A Wait step on this trigger can fire several times for one order. For "do this once per new order", use When an order is created.
  • When a product is updated or sold does not fire for brand-new products. Use When a product is created, or add both triggers.
  • Other apps often write their tags or metafields a few seconds after Shopify sends the webhook. If a condition passes when you test by hand but fails live, add a short Wait step before the first condition.

Did it fire?

The workflow's Metrics page shows whether Shopify's webhook arrived. The Activity page shows each run and, for skipped items, which condition failed. See Understanding Workflow Backlogs if runs are arriving but slow.