Shopify Flow Adds ShopifyQL Action for Analytics

Until this update, Shopify Flow was effective at orchestrating things that happen after a discrete event, a new order, a refund, a stock movement, a subscription renewal. What it could not easily do was reason about the broader state of the business: revenue trends, traffic patterns, inventory positions, returning-customer behaviour. Those numbers lived in the analytics dashboard, and a merchant or agency operator had to look at them manually before deciding whether anything needed to happen.

The new action closes that loop. A workflow can now ask the analytics layer a question, written in ShopifyQL, and use the answer to drive a notification, a tag, a Slack message, or any other downstream step. It moves Shopify Flow from a reactive automation tool to one that can act on the shape of the data, not just the events flowing through the store.

How the action works

Inside the Flow editor, the action takes a ShopifyQL query as its input. ShopifyQL is Shopify’s analytics query language, a SQL-style syntax purpose-built for retrieving sales, session, and inventory data without a separate data warehouse. A typical query might fetch total revenue for the last seven days grouped by sales channel, or returning-customer order count for a specific product over a rolling thirty-day window.

When the workflow runs, the action submits the query, receives the result set, and exposes it to the rest of the workflow as structured variables. Every column the query returns becomes a field that subsequent steps can branch on, compare against thresholds, or interpolate into message templates. The variable system is the same one Flow uses for event payloads, so existing conditions and notification actions work without modification.

Because the query is authored at design time and runs at execution time, the same workflow can be fired on a schedule or in response to an event, depending on the trigger chosen. A scheduled trigger plus a query produces a regular reporting cadence; an event trigger plus a query produces a contextual rule that reacts both to the event and to the wider data state at that moment.

Authoring queries inside Flow does require some familiarity with ShopifyQL syntax, but the language is intentionally narrow and the patterns most workflows need are short. Once a few canonical queries are saved, copying them between workflows becomes the dominant operating mode, and the team can extend coverage incrementally rather than treating it as a separate analytics project.

Examples worth setting up

Shopify’s release note suggests four starting use cases, each of which corresponds to a familiar conversation an agency has with a client. The first is a daily report that summarises sales, sessions, and conversion rate over the previous twenty-four hours and posts it to a shared Slack channel. That is not a new idea; most stores eventually build a version of it. Doing it inside Flow removes the need for a third-party reporting tool or a custom integration, and keeps the logic in one place.

The second is a sales-threshold alert: if revenue drops below a defined floor over a defined window, the workflow emails the merchant or pings a channel. This kind of monitoring is normally implemented as a guardrail on paid media spend, or as a check during peak trading windows, and is the sort of safety net that smaller teams often promise themselves they will set up but never quite get to.

The third is product-level tagging based on sales milestones, automatically applying a “best seller” or “low velocity” tag when a product crosses a threshold over a rolling period. Tags drive collection inclusion, theme rules, and downstream marketing logic, so a tagging rule wired to live data quickly becomes a building block for personalisation. The fourth is a traffic-anomaly alert that notifies the team when sessions drop or spike beyond an agreed band, giving early warning of a tracking outage, a viral moment, or a paid campaign issue.

What this means for UK Shopify merchants

For UK retailers running independent Shopify stores, the value is operational consistency. Many smaller teams set out with intentions to monitor performance daily and gradually drift towards a weekly or monthly review cadence as other priorities crowd in. A workflow that runs every morning, posts the headline numbers into the team channel, and flags anything outside an agreed band is the kind of routine that survives because it does not depend on a person remembering to log in.

For agencies and operators supporting Shopify clients, the action makes it easier to build alerting that matches how each client actually trades. A homeware brand might want a weekly summary by product category. A high-velocity apparel store might want an hourly check on conversion rate during sale windows. A B2B store might want a notification when a named customer’s order count crosses a threshold. All three are ShopifyQL queries inside a Flow workflow, with no separate tooling required and no need to expose analytics access to a third party.

The feature also pairs naturally with disciplined goal tracking on digital marketing and ecommerce programmes. Alerts surface the moment a metric strays from plan; the response strategy still needs to be defined in advance, and the targets, traffic, conversion rate, cost of acquisition, average order value, still need to be set somewhere outside the workflow. The action automates the watching; it does not automate the thinking.

Automation like this works best on a cleanly structured store. Our Shopify web design team builds and configures Shopify stores for UK retailers.

Practical considerations before relying on the action

ShopifyQL is well suited to the metrics that ship with Shopify analytics, but it is not a general-purpose query layer. Custom data, third-party app metrics, finance system numbers, proprietary attribution models, still lives elsewhere and needs to be joined in a separate tool. Where a workflow needs to combine Shopify analytics with a number pulled from outside, the new action is one half of the picture and an external integration is still required for the other half.

Refresh latency also matters. ShopifyQL reads from Shopify’s analytics layer rather than the live transactional database, which means the figures the action returns are accurate as of the most recent analytics refresh rather than the last second. For most monitoring use cases, daily summaries, hourly anomaly checks, milestone tagging, that is acceptable. For decisions that have to react within a minute of a transaction, an event-driven trigger acting on the order payload remains the better tool.

Finally, the action is a complement to, not a replacement for, the analytics dashboard and the formal reporting suite. Period-over-period comparisons, cohort analysis, and full-funnel attribution still belong in dedicated reports, often supplemented by external tools. The value of putting ShopifyQL inside Flow is that the most consequential numbers stop sitting on a dashboard waiting to be looked at, and start triggering the actions they imply. It also pairs with the rest of the analytics surface rather than competing with it. The dashboard now opens with a ranked feed of daily insights, and custom reports support scatter plots and radar charts for the relational questions a single workflow variable cannot answer.

FAQ