Scheduling Snowflake dataflows without an engineering team

What "schedule" actually means

In these guides – and in Refyner – schedule means orchestrating the dependency between transformations and their refresh times. That is a stronger claim than "run at 6am". A real schedule knows that the blended CAC dataflow reads PREP_CHANNEL_SPEND and PREP_ORDERS, so it runs them first, runs CAC after both succeed, and stops the chain – loudly – if either fails.

The distinction matters because the failure mode of timer-based refresh isn't an error message. It's a dashboard full of plausible, stale numbers: spend through yesterday joined to orders through Tuesday. Nobody notices until the numbers drive a bad decision, and then everybody notices.

What a dataflow schedule needs

Whatever tool provides it, production scheduling for everyday analytics comes down to six capabilities:

• Dependency ordering – prep runs before the models that read it, expressed as a chain, not as guessed clock offsets.
• Failure that alerts a person – a failed run pages or emails someone before the business reads the output.
• Run history you can read – when did it last succeed, how long did it take, what changed.
• Retries and safe reruns – transient warehouse hiccups shouldn't need a human, and a manual rerun shouldn't double-load anything.
• Backfills – re-run a dataflow for a historical window without hand-editing dates in SQL.
• Cost visibility – scheduled dataflows burn Snowflake compute; someone should be able to see which ones and how much.

Analyst teams don't fail at scheduling because these are conceptually hard. They fail because in most stacks each item on that list is an engineering project.

The usual options, and where they strain

BI-tool refresh. Power BI Dataflow and similar features re-run one artefact on a timer inside the BI suite. There is no dependency chain across transformations, and the output lives in the BI vendor's storage rather than your Snowflake – which is why we treat refresh and orchestration as different things in Refyner vs Power BI Dataflow.

dbt + Airflow. The engineering-standard answer, and a good one if you have engineers: dbt owns transformations, Airflow owns the DAG. But it is two code-first tools, deployed and maintained as infrastructure, and the people who operate them become the queue every analyst change waits in. The full comparison is in Refyner vs dbt / Airflow.

Desktop prep tools + a server. Prep is drag-and-drop on a desktop, but scheduling means buying and administering the server edition – orchestration priced and operated as a second product.

The DIY baseline: Snowflake tasks

Snowflake's native tasks are the honest baseline every analyst should know, because they prove the mechanics are simple. A task runs SQL on a cron expression; a chained task runs after its predecessor:

-- Prep runs at 05:00 London time, after connectors sync
create or replace task T_PREP_ORDERS
  warehouse = TRANSFORM_WH
  schedule  = 'USING CRON 0 5 * * * Europe/London'
as
  create or replace table PREP_ORDERS as
  select *
  from RAW_SHOPIFY.ORDERS
  qualify row_number() over (
    partition by order_id order by _synced_at desc
  ) = 1;

-- The CAC model runs only after prep succeeds
create or replace task T_MODEL_BLENDED_CAC
  warehouse = TRANSFORM_WH
  after T_PREP_ORDERS
as
  call SP_REBUILD_BLENDED_CAC();

alter task T_MODEL_BLENDED_CAC resume;
alter task T_PREP_ORDERS resume;

This works, and for two or three dataflows it may be all you need. Score it against the six capabilities, though, and the gaps show: no alerting without wiring up error notifications yourself, no lineage view beyond show tasks, backfills mean editing SQL, and every change is DDL in a worksheet – which quietly makes the schedule engineer-owned again, even if the engineer is you at your most careful.

Cadence patterns that work

Cadence is a modelling decision, not a preference. The pattern that holds across eCommerce and subscription teams:

• Daily, early, in dependency order: spend and orders prep right after the connectors finish, then CAC and revenue-after-ad-spend models. These feed trading decisions made that morning.
• Weekly: retention, repurchase and RFM models – behaviour that moves in weeks, scheduled for Monday mornings so the week starts with fresh cohorts.
• Monthly: cohort LTV and LTV:CAC, after the month closes, when the cohort's acquisition spend is final.
• Never intraday by default: ad platforms restate recent spend, so intraday CAC mostly refreshes noise – at real compute cost.

Two disciplines make any cadence trustworthy: sequence dataflows after their sources (a schedule that fires before the connector lands is just an expensive way to copy yesterday), and treat a missed run as an incident with an owner, not a surprise for whoever opens the dashboard first.

Scheduling as an analyst feature

Everything above is why Refyner treats prep and schedule as one tool rather than two. An analyst sets the cadence and dependencies on the dataflow they just built – no second product, no DAG repository – and Refyner runs it as pushdown on your Snowflake, watches every run, and alerts on failure. The built-in models ship with sensible cadences already attached: daily for Blended CAC, weekly for Retention & repurchase, monthly-shaped runs for Customer LTV. Scheduled dataflows are billed at $3 per compute hour, pay-as-you-go, while building and sampling stay free – the detail is on the pricing page.

Keep reading: