Run ShopifyQL from inside a workflow to retrieve sales, sessions, and inventory. The returned values become variables you can pass into downstream conditions and actions.
It could only react to triggers like new orders or inventory changes, which made it hard to make decisions based on "store-wide aggregate values."
Turn ShopifyQL query results into variables. You can wire up threshold checks → Slack notifications / tagging / admin alerts end to end.
Automatically deliver reports containing analytics data to Slack.
Get notified the moment sales drop below a specified amount.
Automatic tagging based on sales performance, such as "Best Seller."
Instantly spot storefront traffic anomalies.
| Item | Traditional Flow | After adding Get analytics data |
|---|---|---|
| Data retrieval method | Event-driven Only deltas such as order and inventory changes | Query-driven Actively retrieve aggregated values with ShopifyQL |
| Available data | Information attached to that event's object | Analytics data such as sales, sessions, and inventory levels |
| Use in downstream processing | Event variables only | Query results as variables Usable in conditions and actions |
| Scheduled reports | Built separately with external tools (BigQuery, Looker, etc.) | Handled entirely within Flow Combined with a Scheduled trigger |
| Threshold alerts | Hard to implement with Shopify alone | Just pass the query result to a Condition |
* The original article does not detail the query syntax. ShopifyQL is a SQL-like query language specific to Shopify; the following is a general illustration.
Queries that previously could only be run in Shopify QL Notebooks or the Admin UI can now be executed as a Flow step. Query results can be reused as variables in later steps can be done.
Things like "run a sales query at 9 AM every day → Slack" or "aggregate sessions every Monday → email"—Scheduled execution × analytics data × notifications this three-tier setup comes together with no code.
The original article only states "refer to the documentation, including limitations." Constraints such as execution frequency, query complexity, and the number of returned rows are not documented = checking the docs before you design is a must.
Use cases where you were "running BigQuery/Looker solely for threshold alerts" can likely be folded into Flow.Redefining the role of your BI stackcould be the catalyst for that.
The official example of "tag a product when it hits a sales target"automatic collection curation, automatic badge display, and automatic price drops and serves as a starting point for chaining with other Flows. If you assign tags best-seller-100 on a per-milestone basis like this, you can also reference them from the Liquid / Online Store editor.
milestone-100/milestone-1000 automatically apply a tag → then use Liquid on the Online Store to swap badges/copy based on the tag.