Salesforce to Snowflake connector and integration tools compared, with sync, zero copy and the delete your pipeline never performs
Twelve ways to get Salesforce objects into Snowflake, and the two facts that decide the project before any feature comparison. Snowflake says its own Salesforce connector "does not support hard deletes in Snowflake", so deleted records stay in your tables forever while every sync reports success. And it says the connector is built for teams who do not use Salesforce Data Cloud, which means a licensing fact picks your architecture. Everything here was read from Snowflake's connector documentation on 8 September 2026.
No credit card required.
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
Vendor documentation read 8 September 2026 · Last updated September 2026
Which Salesforce to Snowflake connector should you use?
One question decides it, and it is not a feature. If your organization owns Salesforce Data Cloud, Snowflake recommends zero copy sharing, which gives you near real-time access with no pipeline to run. If you do not own Data Cloud, Snowflake built its Openflow Salesforce connector for exactly that case, and it is the sensible first-party starting point. Two limits rule it out and neither is a feature comparison: it cannot consolidate multiple Salesforce orgs into one Snowflake database, and it does not perform deletes, so removed records are flagged and kept until you clean them up yourself. If either matters, look at Fivetran, Airbyte, GRAX or a plain Bulk API export instead.
One scoping note before anything else. If this is a one-time extract of a few objects for a single analysis, the cheapest correct answer on this page is a Bulk API export loaded with COPY INTO, and no vendor will tell you that. For the wider vendor landscape see Salesforce integration tools, and for the ongoing warehouse load pattern, Snowflake ETL tools.
Snowflake ships one connector per source, and they do not agree with each other
Openflow is one product family with one connector per source. Put the Salesforce connector next to the MySQL and SQL Server connectors and they answer the same operational questions in different ways, without either page acknowledging the other. The Salesforce one is the outlier on nearly every row, because it polls an API rather than reading a change log. We read all three documentation sets on 8 September 2026. The last column is what we would ship.
| What is at stake | What Snowflake's docs say | Why it matters to a buyer | What we would ship |
|---|---|---|---|
| How a delete is recorded | The Openflow Salesforce connector marks a removed record using isDeleted, which is Salesforce's own business field. The Openflow MySQL and SQL Server connectors both add their own metadata column, _SNOWFLAKE_DELETED, and document it as "whether the row was deleted from the source table". | One vendor, one product family, two different conventions for the same concept. A warehouse team that standardizes on the documented _SNOWFLAKE_DELETED filter across sources will not find that column on Salesforce tables at all, and the isDeleted field it must use instead already carried a Salesforce meaning of its own, namely that the record is in the recycle bin. Neither connector page mentions the other. | Write one view per source that normalizes both spellings to one flag |
| Whether deletes are applied at all | Snowflake states the Salesforce connector "does not support hard deletes in Snowflake" and that you must "run a query on the destination table" or "perform a full refresh" yourself. | The database connectors soft-delete too, so the row survives in all three cases. The difference is what the buyer expects. Nobody reads "Salesforce sync" as "your deleted opportunities stay in the table until you write the delete yourself", and no part of the running pipeline will ever tell you. Every sync reports success while the table grows a permanent tail of records that no longer exist upstream. | Schedule the cleanup query on day one, not after the first bad number |
| What detects a change | The Salesforce connector compares timestamp fields, using SystemModstamp where available and otherwise LastModifiedDate, CreatedDate or LoginTime. The MySQL connector reads the binary log. The SQL Server connector "uses SQL Server Change Tracking (CT) to detect changes in the source tables". | Two of the three read a change log, so they see every intermediate state and every delete as an event. The Salesforce one takes a photograph on a timer and compares it to the last photograph. Any record changed twice between refreshes lands once, and anything that updates a row without moving its timestamp is invisible. This is polling sold under the same product name as change capture. | Treat Salesforce tables as periodic snapshots, never as an audit trail |
| Formula and derived columns | Snowflake documents that formula fields "are not replicated as data from Salesforce". The connector retrieves the expression from the Describe API, translates it to Snowflake SQL and generates a view. Where translation fails, "the corresponding column in the view returns NULL and the column comment indicates the failure reason". | The database connectors have no equivalent behavior, because a computed column in MySQL or SQL Server arrives as a value. Here the number in your warehouse is recomputed by a translation layer rather than copied from the system of record, so Salesforce and Snowflake can legitimately disagree about the same field. Rollup summary fields, VLOOKUP, REGEX and $User references are all listed as unsupported, which covers a great many revenue formulas. | Query the view comments for translation failures before trusting a column |
| Multiple sources into one database | Snowflake states you "cannot consolidate data from multiple Salesforce instances into a single database in Snowflake". The database connectors carry no equivalent restriction. | This is the row that kills projects, and it is one sentence in a limitations list. Consolidated reporting across two or three Salesforce orgs is one of the most common reasons a US company funds this work at all, particularly after an acquisition, and it is precisely the job the free first-party option refuses. You find out during implementation rather than during evaluation. | Count your Salesforce orgs before you shortlist, not after |
| Object relationships | For the Salesforce connector, "traversing object relationships and fetching related objects is not supported". You replicate flat objects only. | Reasonable, and worth knowing early. Salesforce data is heavily relational and most useful questions span Account, Opportunity, Contact and custom objects. You configure each object separately and rejoin them in Snowflake, which means the join logic your Salesforce reports gave you for free is now warehouse code somebody owns and maintains. | Budget the modelling layer as part of the project, not as a follow-up |
| Custom Salesforce domains | A single line in the limitations: "Custom Salesforce domains are not supported." | Snowflake does not define the term, and it matters, because Salesforce uses custom domain for a specific feature that serves your org on a domain you own, which is separate from the My Domain and enhanced domains that Salesforce has required across all orgs since Winter 24. We are not going to guess which one Snowflake means. This is worth one direct question to both vendors before you commit, and any vendor who has run this route in production will answer it immediately. | Confirm in writing against your actual login URL before you commit |
| What the connector is for | Snowflake says this connector is "designed for users who do not use Salesforce Data Cloud", and that zero copy "is recommended if you use Salesforce Data Cloud and require near real-time bidirectional integration". | The most useful sentence in the documentation and the one nobody quotes. The vendor is telling you the product selection is decided by a Salesforce licensing fact, before any feature comparison. If you own Data Cloud, the replication connector is not the intended path. If you do not, zero copy is not available to you at any price until you buy a separate Salesforce product. | Answer the Data Cloud question first, then compare tools |
None of this makes the documentation wrong and we would still start with it. It makes the point that a connector family is a set of separately built products rather than one consistent contract, even when one vendor owns all of them and the destination. The first two rows are the ones to act on today, because a delete that never happens is invisible until a number is wrong in a board deck. The same comparison for the database sources is on MySQL to Snowflake migration tools and SQL Server to Snowflake migration tools.
The four mechanisms buyers keep confusing
Most confusion on this route comes from treating "Salesforce to Snowflake" as one thing. It is four different products with different owners, different bills and different failure modes. Two of them require a Salesforce Data Cloud license and two do not, which is the first fork in any evaluation.
| Mechanism | Owner | How it moves data | Who it is for | What to watch |
|---|---|---|---|---|
| Openflow Salesforce Bulk API connector | Snowflake | Polls the Bulk API 2.0 on a 1 minute to 24 hour schedule, compares SystemModstamp, merges into the target | Teams on Snowflake who do not own Salesforce Data Cloud | Soft deletes only, one Salesforce org per database, no relationship traversal, formula fields recomputed as views. |
| Data Cloud zero copy sharing | Salesforce and Snowflake | Snowflake reads shared Data Cloud data in place, with no pipeline and no second copy | Organizations that already own Data Cloud and need near real-time both ways | Requires Salesforce Data Cloud, a separately licensed product. Snowflake publishes no route to this without it. |
| Data Cloud Sync Out | Salesforce | Salesforce pushes Data Cloud objects out to your Snowflake account on a schedule | Data Cloud owners who want a physical copy in Snowflake rather than a share | Also gated behind Data Cloud, and the copy is only as complete as the objects you ingested into Data Cloud first. |
| Third-party ELT | Fivetran, Airbyte, Matillion and others | Extracts through the Salesforce APIs and loads to Snowflake, usually with its own schema handling | Teams with several sources who want one pipeline vendor for all of them | Every vendor solves deletes and formula fields differently. Ask both questions specifically rather than accepting "we sync Salesforce". |
Salesforce to Snowflake connectors and integration tools compared
Pricing models rather than price tags, because every vendor here except us either quotes or meters, and any figure printed on this page would be stale within a quarter. Neither Snowflake nor Salesforce publishes a list price for the paths they recommend, so this page says that instead of inventing one. Where a tool is wrong for a job, the last column says so.
| Tool | Approach | Best for | Billing unit | What to watch |
|---|---|---|---|---|
| Snowflake Openflow | First-party managed connector polling the Salesforce Bulk API 2.0 | Snowflake teams without Salesforce Data Cloud | Snowflake credits, metered as warehouse and service time | Soft deletes only, and it cannot consolidate two Salesforce orgs into one database. Snowflake states it is built for teams who do not use Data Cloud. |
| Data Cloud zero copy | Shared access to Data Cloud objects with no replication | Existing Data Cloud owners wanting bidirectional freshness | Salesforce Data Cloud licensing, plus Snowflake compute on query | The entry ticket is a separately licensed Salesforce product. If you do not own Data Cloud this option does not exist for you. |
| Fivetran | Fully managed ELT with schema drift handling | Teams who want zero pipeline maintenance across many sources | Monthly active rows | The initial history load is the largest active-row month you will ever have, and it bills at that scale before anyone has validated the mapping. |
| Airbyte | Open source connector framework, self-hosted or cloud | Engineering teams who prefer to own and patch the pipeline | Free self-hosted, capacity-based in cloud | Self-hosting moves the cost from a license to your on-call rota. Salesforce API limits are yours to manage rather than the vendor's. |
| Matillion | Load plus in-warehouse transformation | Teams wanting the modelling layer and the pipeline from one vendor | Credit-based consumption | The transformation layer is the product. If you only need Salesforce objects landed in Snowflake you are paying for a great deal you will not switch on. |
| Stitch | Managed replication built on the Singer specification | Straightforward object replication on a predictable budget | By rows loaded per month | A simpler product than the rest of this list, which is the point. Less control over the schema and less help when Salesforce changes underneath you. |
| Hevo Data | Managed no-code pipelines with in-flight transformation | Smaller teams wanting a managed pipeline without enterprise pricing | By events loaded per month | Event metering behaves like row metering during the initial load, which is exactly when volume spikes and the mapping is still unvalidated. |
| Estuary Flow | Streaming pipelines with a persistent change log | Low latency across several sources without operating Kafka | By data volume and connector | You are buying a streaming platform. Salesforce itself is polled through an API, so the lowest latency link in your chain will not be this one. |
| GRAX | Salesforce-specialist replication that preserves history and schema | Teams who need the full history of every record, including deletions | Quoted, by data volume | Narrower than the generalists and priced as a specialist. If you have five sources and Salesforce is one of them, this solves a fifth of the problem. |
| Salesforce Connect | Query external data from inside Salesforce via external objects | Showing Snowflake data inside Salesforce, which is the opposite direction | Salesforce licensing | Frequently suggested on this route and usually the wrong answer, because it brings Snowflake into Salesforce rather than Salesforce into Snowflake. |
| Bulk API export plus COPY INTO | Scheduled Bulk API extract to files, staged, loaded with COPY INTO | A one-time analysis or a small number of objects on a slow cadence | Free, beyond the Snowflake warehouse time to load | Cheapest option here by a wide margin and the right answer more often than vendors admit. You own the incremental logic, the deletes and the retries. |
| Adapters | Field-level mapping you set once, then scheduled incremental sync | Teams who want the mapping explicit and the bill flat | Flat $49 a month, not metered by rows | We are not a Salesforce archival product, we do not do sub-second streaming, and we do not do in-warehouse modelling. |
Six facts worth knowing before you sign anything
No hard deletes
Snowflake's own description of its Salesforce connector. Deleted records are flagged with isDeleted and remain in the destination table until you run a delete query or a full refresh yourself.
Openflow Connector for Salesforce Bulk API, read 8 September 2026
1 min to 24 h
The configurable refresh window. Change detection is a timestamp comparison rather than a change log, so states between two refreshes are never recorded.
Openflow Connector for Salesforce Bulk API, read 8 September 2026
One org per database
You cannot consolidate data from multiple Salesforce instances into a single Snowflake database with the first-party connector. Often the exact job the project was funded to do.
Openflow Connector for Salesforce Bulk API, read 8 September 2026
isDeleted vs _SNOWFLAKE_DELETED
Two delete conventions inside one Snowflake connector family. The Salesforce connector reuses a Salesforce business field; the MySQL and SQL Server connectors add their own metadata column.
Openflow connector documentation for Salesforce, MySQL and SQL Server, read 8 September 2026
Recomputed, not copied
Formula fields are translated into Snowflake SQL and served through generated views. Unsupported constructs return NULL with the reason left in a column comment.
Openflow Connector for Salesforce Bulk API formula fields, read 8 September 2026
Data Cloud decides
Snowflake says the replication connector is designed for users who do not use Salesforce Data Cloud, and recommends zero copy for those who do. A licensing fact picks your architecture.
Openflow Connector for Salesforce Bulk API, read 8 September 2026
Eight ways this pipeline goes wrong while every check stays green
A Salesforce pipeline rarely fails loudly. It succeeds, the run log is clean, the row count went up, and a number somewhere is wrong. These are the eight we would check for on any existing Salesforce to Snowflake pipeline before believing a single figure it produces.
| The failure | What you see | What is actually happening |
|---|---|---|
| A table that only ever grows | Every sync reports success and your opportunity count drifts above what Salesforce reports. | Snowflake states the connector "does not support hard deletes in Snowflake". Deleted records are flagged with isDeleted and left in place. Nothing in the pipeline surfaces this, and the gap widens slowly enough that it reads as growth rather than as a bug. Pipeline reports and win rates are wrong from the first deletion onward. |
| A revenue formula that came back empty | A formula column exists in Snowflake, is fully populated in Salesforce, and is NULL for every row. | Formula fields are recomputed in Snowflake from a translated expression, not copied. Snowflake lists rollup summary fields, VLOOKUP, REGEX, ISCHANGED and $User global variables as unsupported, and states that unsupported constructs return NULL "and the column comment indicates the failure reason". The reason is sitting in a column comment nobody queries. |
| A cross-source delete filter that finds nothing | A warehouse-wide model excluding deleted rows compiles for your database sources and behaves differently for Salesforce. | The MySQL and SQL Server connectors write _SNOWFLAKE_DELETED. The Salesforce connector uses Salesforce's own isDeleted field. One vendor, one product family, two spellings for one idea, and no page mentions the other. Any macro written against one convention needs a special case for the other. |
| Updates that never arrive | Records change in Salesforce and the Snowflake copy stays on an older version indefinitely. | Change detection is a timestamp comparison against SystemModstamp, or LastModifiedDate, CreatedDate or LoginTime where that is missing. Anything that modifies a record without advancing the timestamp it happens to be using is invisible to the connector. There is no log to fall back on, so the row simply is not selected and no error is raised. |
| Intermediate states that vanish | An opportunity moves through three stages in an afternoon and Snowflake shows only the last. | The connector polls on a schedule of 1 minute to 24 hours and merges the current state. It is not reading a change log, so any transition between two refreshes leaves no trace. This is fine for a dashboard of current pipeline and quietly useless for stage-duration or velocity analysis, which is often exactly why the warehouse was funded. |
| The second org nobody scoped | The pipeline works perfectly for one Salesforce org and cannot be pointed at the second. | Snowflake states you "cannot consolidate data from multiple Salesforce instances into a single database in Snowflake". Discovered during implementation, this is a re-platform rather than a configuration change, and consolidated cross-org reporting is frequently the business case that funded the project. |
| Attachments that were never in scope | Objects sync cleanly and every document is missing. | Fields of type base64, which is how Attachment.Body and ContentVersion.VersionData are stored, need a dedicated ingestion path, and files attached to records are ignored. Location and address fields are also unsupported and are ignored outright, so a compound address column arrives as nothing at all rather than as an error. |
| A job that sits in progress forever | One object stops updating while the rest of the pipeline looks healthy. | Snowflake documents an object type stuck in IN_PROGRESS status, caused by FlowFiles deleted manually before the connector state was updated, and warns that this "can cause a job to remain in the IN_PROGRESS status indefinitely". A per-object stall does not look like an outage on any dashboard that checks whether the connector is running. |
Six steps that decide whether this project works
Step 1
Answer the Data Cloud question before anything else
Snowflake tells you which path it intends you to take, and almost nobody reads it. If your organization owns Salesforce Data Cloud, zero copy sharing is the recommended route and replication is the fallback. If it does not, zero copy is unavailable at any price until you buy a separate Salesforce product, and the Openflow connector is what Snowflake built for you. Ten minutes with whoever owns the Salesforce contract removes most of the vendor list.
Step 2
Count your Salesforce orgs
One sentence in the limitations decides whether the free first-party option can do the job: you cannot consolidate multiple Salesforce instances into a single Snowflake database. If your company has grown by acquisition and runs two or three orgs, and cross-org reporting is the business case, the first-party connector is out before the evaluation starts. Better to know that in week one than in month three.
Step 3
Inventory your formula and rollup fields
Query the object metadata for every formula field, then check each expression against the supported function list. IF, CASE, the text functions, the basic math and date functions and ISPICKVAL all translate. Rollup summary fields, VLOOKUP, REGEX, IMAGE, HYPERLINK, ISCHANGED, ISNEW and the $User and $Organization globals do not, and those columns will be NULL. On a mature Salesforce org this is usually a short list carrying a lot of reported revenue.
Step 4
Decide what a deleted record means to you
The connector will never remove a row. Decide up front whether your warehouse should mirror Salesforce, in which case you schedule a cleanup query against isDeleted from day one, or whether you actually want the history, in which case the soft delete is a feature and you filter it in every downstream model. Both are defensible. Making no decision means the second option happens by accident and nobody knows.
Step 5
Write the delete filter once, in one place
If Snowflake also holds database sources, you now have two spellings for deleted: isDeleted from Salesforce and _SNOWFLAKE_DELETED from the MySQL and SQL Server connectors. Normalize both into one flag in a staging view per source, so every model downstream filters the same way. Doing this on day one costs an hour. Doing it after three teams have written their own filters costs considerably more.
Step 6
Reconcile on values, never on row counts
Per object, compare the record count against Salesforce with deleted records excluded, the SUM of every currency field, MIN and MAX of every date, and a count grouped by stage or status. Then check every formula column for an all-NULL result. Row counts reconcile perfectly on a load that recomputed three formulas into nothing and is quietly retaining every record deleted since go-live.
Why US teams fund this project
Pipeline reporting that Salesforce reports cannot answer
The most common reason this gets funded. Report builder runs out somewhere around multi-object joins and long history, and the analytics team wants SQL against the whole funnel rather than another dashboard component.
Joining CRM to product and billing data
The warehouse already holds Stripe, NetSuite or the application database, and Salesforce is the last source that cannot be compared against the rest of the business. Revenue attribution needs all of them in one place.
Consolidating several Salesforce orgs after an acquisition
Common, valuable, and the case the first-party connector explicitly refuses. Worth naming as a requirement early, because it eliminates the free option and changes the shortlist entirely.
Retaining history Salesforce does not keep
Field history tracking is limited and storage is expensive, so teams land a full copy in Snowflake and keep it. Here the connector's soft delete behavior stops being a trap and becomes the reason you chose it.
Feeding forecasting and scoring models
Data science work needs the whole opportunity history in one queryable place. Note the polling limitation: a timestamp-compared snapshot supports current-state modelling well and stage-duration modelling poorly.
Reporting across a Salesforce migration
While two CRMs run in parallel, the warehouse is the only place the numbers can be compared. A temporary need that reliably outlives its own timeline.
Five jobs where you should not pick us
A comparison page that never says the competition wins is an advert. These are the cases where we are the wrong answer and something on the list above is the right one.
- A genuine one-time extract of a few objects for a single analysis. Use the Bulk API and COPY INTO. It is free and it costs less than we do.
- Full Salesforce archival with every historical version of every record retained for compliance. That is a specialist product and GRAX is built for exactly it.
- Zero copy access from Snowflake to Data Cloud with no pipeline at all. If you already own Data Cloud, that is Snowflake and Salesforce's own recommendation and no third party improves on it.
- Bringing Snowflake data into the Salesforce UI as external objects. That is Salesforce Connect and it runs the other direction from everything on this page.
- Heavy in-warehouse modelling as well as the pipeline. Land the data with us if you like, but the transformation layer belongs in dbt or Matillion.
Four questions to ask any vendor on this list
What happens to a record I delete in Salesforce?
The fastest way to find out whether a vendor has actually run this route. Snowflake's own connector does not delete it and will not tell you. Ask whether the row is removed, flagged, or left untouched, ask which column carries the flag, and ask to see it. A vendor who answers "we keep them in sync" without naming a column has not thought about it.
How do you handle formula and rollup summary fields?
The question that separates a Salesforce pipeline from a generic one. Values can be copied or recomputed, and Snowflake's connector recomputes them from a translated expression, with unsupported functions returning NULL. Ask which of your specific formula fields survive. Rollup summaries and VLOOKUP are the ones that usually carry the money.
Can you load two Salesforce orgs into one database?
Ask it plainly, because the first-party option cannot. If consolidated cross-org reporting is the business case, this single question reorders your shortlist. Ask how record IDs are kept distinct across orgs too, since Salesforce IDs are only unique within an org.
Is this polling or change capture, and how do you say so?
Both get sold as sync. Polling compares a timestamp on a schedule and shows you current state; change capture reads a log and shows you every transition. If you need stage duration, velocity or an audit trail, polling cannot give it to you at any refresh frequency, and a vendor should say that rather than offer a shorter interval.
Related integration and warehouse guides
Salesforce is one source into Snowflake among several. These cover the wider Salesforce integration question, the neighboring database sources whose connectors this page is compared against, and the ongoing load pattern once the first sync is running.
Salesforce integration tools
The hub above this page: API limits, licensing and the wider Salesforce vendor landscape.
Salesforce to Snowflake connector pricing
What each route actually bills you for, and why the Data Cloud question comes first.
Sync Salesforce to Snowflake
The implementation walkthrough: objects, incremental logic and the merge.
MySQL to Snowflake migration tools
The connector this page is compared against, where deletes are spelled a different way.
Snowflake ETL tools
The ongoing load case across every source, once the first pipeline is running.
Reverse ETL tools
The return trip, when a warehouse model needs to land back in Salesforce.
Questions buyers ask about Salesforce to Snowflake integration
- How do I connect Salesforce to Snowflake?
- There is no direct link. Snowflake cannot query Salesforce and Salesforce cannot write to Snowflake, so something sits between them: Snowflake Openflow, a managed pipeline such as Fivetran, an open source extractor, or Salesforce Data Cloud sharing a table. Which one you can use is decided by whether you own Data Cloud, not by a feature comparison.
- What is the best Salesforce to Snowflake connector?
- Snowflake Openflow is the first-party answer if you do not run Salesforce Data Cloud, because Snowflake says that connector is built for exactly that case. If you do run Data Cloud, Snowflake points you at zero copy sharing instead. Establish which side of that fork you are on before shortlisting anything, because it eliminates most of the market immediately.
- How does Salesforce to Snowflake sync work?
- The Openflow connector polls rather than streams. It calls the Salesforce Bulk API 2.0, compares a timestamp field to find what changed, then merges the result into the destination table. You choose a refresh frequency between 1 minute and 24 hours. That is a scheduled comparison, not change data capture, and it behaves differently from a log-reading database connector.
- Does the Salesforce to Snowflake connector handle deletes?
- Not as deletes. Snowflake states plainly that the connector "does not support hard deletes in Snowflake". A record deleted in Salesforce is flagged with isDeleted set to true and the row stays in your table forever. You have to run your own delete query or a full refresh. Row counts keep climbing while every sync reports success.
- What is Salesforce to Snowflake zero copy?
- Zero copy means Snowflake reads Salesforce Data Cloud data through a share instead of replicating it, so there is no pipeline and no second copy to keep current. It is the option Snowflake recommends when you need near real-time bidirectional integration. The catch is the entry ticket: it runs through Data Cloud, which is a separately licensed Salesforce product.
- How much does Salesforce to Snowflake integration cost?
- Three bills, and the connector is usually the smallest. You pay Snowflake for the warehouse time to land and merge the data, you pay whichever pipeline vendor you choose on their own metric, and if you take the zero copy route you pay Salesforce for Data Cloud. Neither Snowflake nor Salesforce publishes a list price you can budget from without a conversation.
- Can I sync Salesforce formula fields to Snowflake?
- Partly, and this is the trap on the route. Snowflake does not replicate formula values. It reads the formula from Salesforce metadata, translates it into Snowflake SQL and builds a view that recomputes it. Anything it cannot translate returns NULL with the reason in a column comment, so rollup summaries and VLOOKUP formulas arrive empty rather than wrong.
- How often can Salesforce data refresh in Snowflake?
- From every minute to once a day. Snowflake documents a configurable refresh frequency of 1 minute to 24 hours. Picking one minute is rarely free, because each refresh is a Bulk API round trip plus warehouse time to merge, so the cost of freshness is paid on both sides of the pipeline every single cycle.
- Can I load two Salesforce orgs into one Snowflake database?
- Not with the first-party connector. Snowflake states that you "cannot consolidate data from multiple Salesforce instances into a single database in Snowflake". For a US business that grew by acquisition and runs two or three orgs, that single sentence rules out the free option for the exact reporting job the project was funded to do.
- Should I use Fivetran for Salesforce to Snowflake?
- Fivetran suits teams who want the pipeline to be somebody else's problem and have steady record volume. Price the first month separately, because the initial history load is the largest month you will ever have. Also ask how it handles deletes and formula fields, since those are the two places every Salesforce pipeline quietly differs.
For the Salesforce-side limits that shape every pipeline on this page, read the Salesforce integration user license. For moving warehouse data back into the CRM, see Snowflake to Salesforce, and for the wider vendor landscape, the best data integration tools.
Land Salesforce in Snowflake with the mapping written down
Map the objects once, run the backfill, then let the same mapping run incrementally with retries, alerts and per-record logs. From $49 a month, not metered by rows.
No credit card required.