Snowflake connector

The Snowflake connector lets a Neblex workflow or agent treat a Snowflake account as both a destination and a source: load records into it, run queries against it, keep tables in sync with an upstream system, and pick up changed rows on a schedule, without a separate ETL tool in the middle.

• Runs against any warehouse, database, and schema the connection role can use
• Execute Snowflake SQL runs any statement, from a lookup to a MERGE, with values from the record passed as bind parameters
• List tables and List table columns read the schema on demand, so new tables and columns need no connector update
• A Poll for changes trigger can run your query on a schedule, and native log capture (Experimental) reads Snowflake change tracking

The three jobs this connector is picked for most often, and what each one gets you.

• Land upstream data without an ETL tool. CRM, billing, and ERP records are merged into warehouse tables by key, with every load visible as a run you can inspect.
• Push model output back to the business. Scores and segments computed in Snowflake are written back to the CRM or support tool on a schedule.
• Let an agent query the warehouse read-only. An AI agent answers plain-language questions with SQL run under a read-only role, and shows the query it used.

The replication flow data teams turn on first.

Keep ANALYTICS.CRM.OPPORTUNITY in sync with Salesforce

Opportunity changes from Salesforce are merged into Snowflake on the record ID, with deletes handled as soft deletes.

1. 1
   Trigger: a Live stream trigger on Salesforce Change Data Capture for /data/OpportunityChangeEvent, which starts a run for each change as it arrives.
2. 2
   Shape: map the Salesforce payload to the warehouse column names and types.
3. 3
   Merge: Execute Snowflake SQL with MERGE INTO ANALYTICS.CRM.OPPORTUNITY t USING (SELECT ...) s ON t.ID = s.ID, updating on match and inserting when not matched, with the values passed as bind parameters.
4. 4
   Deletes: for a delete event, set IS_DELETED = TRUE and DELETED_AT = CURRENT_TIMESTAMP() rather than removing the row.
5. 5
   Reconcile: a nightly flow compares row counts with Salesforce and reloads any gap.

Common patterns other teams start from with this connector.

• Reverse ETL to the CRM. A scored-accounts model in Snowflake writes fit scores and segments back onto Salesforce accounts every hour. (Data)
• Daily revenue snapshot. A scheduled query rolls up recognized revenue and posts the summary to a finance channel with a link to the run. (Finance)
• Event stream landing. Product events from Kafka arrive through a Live stream trigger and are inserted into a raw table in batches. (Data)
• Analytics question agent. An agent answers plain-language questions by writing a query, running it with a read-only role, and returning the result with the SQL it used. (Agentic)

Any object the connection role can see, through SQL. List tables and List table columns read the schema on demand.

Object types

Databases, Schemas, Tables, Views, Materialized views, Streams, Stages, File formats, Tasks, Sequences

The connector never creates objects implicitly. A flow that needs a scratch or control table does so with an explicit Execute Snowflake SQL step, so nothing appears in your account that is not in a flow you can read.

The connection uses a Snowflake user and role, so access is exactly what that role grants and no more.

• Key pair authentication. The connection holds your account identifier, user, and private key, stored encrypted. No password is stored.
• Role-scoped access. Point the connection at a purpose-built role with grants on only the databases and schemas the flows need.
• Network policy and private connectivity. Works behind Snowflake network policies, and through an On-Prem Worker where the account is only reachable from your network.
• Run history. Every run shows each step's status and errors, next to Snowflake's own query history; record data from successful runs is kept when the flow is set to keep run data for replay.

The shape of Snowflake's limits, as published at the time of writing. Verify the exact figures for your account; they change without notice.

• A single statement runs up to the warehouse statement timeout, default 172,800 seconds, usually set far lower
• Large results flow through the run in bounded pieces rather than as one block
• Files already in a stage load fastest with COPY INTO; rows from a flow are written with INSERT or MERGE in batches
• The connector does not retry on its own; turn on Retry on failure for steps that should try again on transient errors
• Compute cost is the warehouse's, not Neblex's. A flow can pick a smaller warehouse for lookups and a larger one for backfills