Salesforce to Snowflake: How to Move Your Data
Replicate Salesforce into Snowflake with Airbyte. Choosing which objects to sync, why syncs end early reporting success, and the formula field trap.
Replicating Salesforce to Snowflake is one of the most common pipelines in any company that sells something, and the hard part is not the connection. It is deciding what to bring across. A mature Salesforce org exposes hundreds of objects, most of which nobody will ever query, and syncing all of them is how teams exhaust their API budget on data no one reads.
This guide covers the managed path with Airbyte, and it treats stream selection as the design work rather than an afterthought. It also covers a behaviour that surprises people the first time they see it: a Salesforce sync can report success having moved considerably less than you expected, and that is by design.
Salesforce to Snowflake at a glance:
Why move data from Salesforce to Snowflake?
Two situations account for most of these pipelines.
The first is joining the commercial picture together. Salesforce knows what was sold and by whom. Your product database knows whether those customers actually use anything, your billing system knows whether they paid, and your support tool knows how much they cost to serve. None of those questions can be answered inside Salesforce, and all of them can be answered in a warehouse.
The second is reporting load. Salesforce reports are fine until someone wants a five-year trend across custom objects, at which point you are fighting a transactional system to do analytical work. Moving the data lets analysts use SQL and leaves the CRM to serve the sales team.
What do you need before you start?
Two credentials decisions and two that determine whether this pipeline behaves:
A dedicated integration user. The connector sees exactly what the authenticating user sees, so field-level security and sharing rules on that account decide what reaches Snowflake. Use a deliberately scoped integration user rather than an administrator's login, and document what it can see, because that is now part of your data model.
A shortlist of objects. Decide before you open Airbyte which objects anyone will actually query. Accounts, contacts, opportunities, leads and your custom objects usually cover it. Selecting everything is the single most common mistake on this connector and it is paid for daily in API calls.
A share of the daily API budget. Salesforce enforces a daily request limit across the org, and every connected application draws from it. Agree your share with whoever owns Salesforce before setting a schedule, because exhausting it affects other people's integrations rather than only yours.
Snowflake objects and a role. A warehouse, database, schema and a role with permission to create tables in that schema. A dedicated role is worth the two minutes, because warehouse credit consumption then has an obvious owner.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the Snowflake side before you begin.
How do you build a Salesforce to Snowflake pipeline in Airbyte?
Step 1: Agree the object list with the business
Sit down with whoever runs Salesforce operations and list the objects and custom objects your analysts need. They will know which custom objects are actively used and which are abandoned experiments from a previous administrator, and that knowledge is not discoverable from the schema. This conversation is the highest-value half hour in the build.
Step 2: Configure the Salesforce source
Click Sources in the left navigation, then New Source, and select Salesforce, following adding a source. Authenticate as your integration user and set a start date. Set the lookback window deliberately too: Salesforce's API is eventually consistent, so a record modified just before a sync may not be visible to it, and the lookback re-reads a short window behind the last cursor position to catch those. The default is ten minutes.
Step 3: Configure the Snowflake destination
Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role with your authentication method. Airbyte creates one table per stream with its own metadata columns alongside your data, so warn whoever reviews the schema that those are expected.
Step 4: Use incremental append and deduped
Click Connections, then New connection, select your objects, and choose incremental append and deduped as the sync mode. On any org of size this is not really a choice, for the reason in the next section. Deduplication also makes the lookback window free, because re-reading an overlapping period does not create duplicate rows in the destination.
Set a frequency that fits your share of the API budget. Hourly syncs of twenty objects consume considerably more than nightly syncs of five, and CRM data rarely needs to be fresher than the meetings it informs.
Why does a successful sync sometimes move less data?
When the connector reaches your org's daily API limit it does not fail. It stops where it is, reports the run as successful, and picks up from that position on the next run. That is sensible, because failing the whole sync would discard work already done, and over a day or two the data catches up on its own.
The self-correction only works on incremental sync. Configure full refresh against a large org and every run truncates somewhere arbitrary, then starts from the beginning again next time, never reaching the end. That is why the sync mode in step 4 is stated as a requirement rather than a recommendation.
It also means a green sync is not proof of completeness on the day it happens. If a downstream model computes daily figures, give it a way to notice that a table stopped receiving records mid-day, because Salesforce's behaviour here is designed to be quiet.
What changes in Salesforce without changing your data?
Formula fields are the important case. The connector syncs the output of a formula rather than the formula itself, which is correct, and editing that formula does not change any record's modification timestamp. Incremental sync therefore never re-reads those records, and Snowflake keeps serving values calculated under the old formula indefinitely, with no error anywhere.
The fix is manual: reset the stream and run a historical backfill. The prevention is procedural, and it is worth writing down where your Salesforce admins will see it. Changing a formula means telling the data team, in the same way a schema change would.
One data quirk belongs alongside it. Bulk API results arrive as CSV, which cannot distinguish an empty cell from the literal text inside it, so values such as NA, N/A, NULL, None and NaN become null by default. If your org legitimately uses those, a country code or a status, enable the option to preserve them. It affects Bulk API streams only, since REST-synced streams keep them as they are.
Frequently asked questions
Why did my Salesforce sync succeed but move fewer records?
It hit your org's daily API limit. The connector stops there, reports success, and resumes from that point next run. On incremental sync this is self-correcting.
Records are missing from Snowflake. What should I change?
Increase the lookback window from the ten minute default. Salesforce's API is eventually consistent, and a longer window catches records that were not visible when the sync ran.
Why are my formula field values out of date?
The formula changed but the records did not, so incremental sync never re-read them. Reset the stream and run a historical backfill to pull the recalculated values.
Which Salesforce objects should I sync?
Only the ones people will query. Agree the list with your Salesforce operations team, who know which custom objects are live and which are abandoned. Selecting everything wastes API budget on data nobody reads.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven, from creating the source through to scheduling the connection. If you would rather manage pipelines as infrastructure, the same source, destination and connection can be provisioned from configuration files instead.
Get your Salesforce data into Snowflake
Agree the object list before you configure anything, use a scoped integration user, run incremental append and deduped so partial syncs resume, and tune the lookback window when records go missing rather than assuming the connector is broken. Then tell your Salesforce admins that changing a formula requires a stream reset.
Airbyte's connector catalog includes 600+ pre-built connectors, so the same Salesforce source can feed other systems without rebuilding anything. For the same source into a relational destination, see Salesforce to PostgreSQL, and for Microsoft's CRM stack and its change tracking approach, Microsoft Dataverse to Snowflake.
Integrate with 600+ apps using Airbyte
Move data from 600+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.