Skip to main content
A query-based source: the extract is a SELECT with a watermark predicate, run on a schedule. The types are where the care goes — NUMBER and TIMESTAMP_NTZ both need deliberate handling on the way out.

What you need

  • A role with SELECT on the source tables, and a warehouse to run on
  • An Octave workspace API key, from Settings → Integrations
  • Somewhere to run a scheduled job — AWS, GCP or Azure

Where this runs

There is no object-landing event to hook, so this runs on a timer. A scheduled function that queries Snowflake and posts the results is the usual shape; keeping it inside Snowflake as a Task is possible but buys less than it costs.

The prompt

Copy this into Claude Code, Cursor or any coding agent. It carries the whole flow — reading your warehouse, mapping the columns, posting to Octave, and deploying the result. Fill in section 1 with your real schema and a few sample rows (DESCRIBE TABLE analytics.gtm.opportunities plus SELECT * … LIMIT 5). The more of your actual data it can see, the less it has to guess.
The instruction to show the mapping as a table and wait for confirmation is the part worth keeping. Without it an agent guesses at your column names and buries the guess inside a handler, where a wrong eventType looks exactly like a right one until the data is in.

Hints worth adding

These are the things that go wrong with Snowflake specifically. Paste whichever apply into section 1 of the prompt — an agent cannot infer them from a schema. NUMBER(18,2) becomes a float somewhere on the way to JSON. Ask for TO_VARCHAR(amount) in the query and amount sent as a string, or deal values arrive subtly wrong and nobody notices for a quarter. TIMESTAMP_NTZ carries no timezone. Whatever the pipeline does with it is an assumption. Say which zone the column is really in and ask for an explicit CONVERT_TIMEZONE('UTC', …) at the boundary. An unbounded backfill query keeps the warehouse busy for the whole run. Ask for the history to be walked in date ranges rather than issued as one query — it is the difference between a predictable bill and a surprising one.