Scattered data is the silent killer of analytics and AI initiatives. When customer, product, marketing, and operational data live in separate systems that never reconcile, every dashboard is suspect and every AI model is grounded in a fraction of the picture. Snowflake is the cloud data platform we reach for when data needs to flow across Salesforce, ERP, marketing, product analytics, and AI workloads at scale, and be trusted when it gets there.
We build the Snowflake foundation: architecture, data engineering, integration with the operational systems where data is born, and the security and governance that keep it trustworthy. Increasingly the most valuable work is grounding AI in Snowflake data, via Cortex and external retrieval, so the agents and models you build answer from your real, unified data instead of guessing.
The usual failures: a powerful platform used as an expensive database, with no real architecture behind it; integrations that load data but never reconcile it, so the warehouse inherits the same conflicts it was meant to resolve; and governance bolted on after the fact in an environment where it should have been a design input. We architect around the decisions and the AI the data will feed, and we build the governance in.
Data and governance have been core to our Salesforce and AI delivery since 2017. We connect Snowflake to the operational systems that matter and ground your AI in it, because a unified, trustworthy data foundation is what makes everything built on top of it actually work.
The engagements we run most often on Snowflake, from first implementation through optimization.
Account design, role-based access, virtual warehouse strategy, cost controls, and environment management.
Snowpipe streaming, dbt transformations, change-data-capture, and reverse-ETL pipelines back to operational systems.
Native Salesforce-Snowflake integration with Data Cloud, Sync Out, Bring Your Own Lake, and reverse-ETL.
AI workflows powered by Cortex, including search, document AI, and Cortex Analyst for natural language analytics.
Tag-based masking, row access policies, data classification, and audit-ready governance frameworks.
Inbound and outbound data sharing, marketplace integration, and cross-account collaboration architectures.
Engagements are measured by movement on the numbers that matter. These are the directions of travel we commit to.
Predictable phases. Clear deliverables. No surprises.
One to two working sessions to map your current state, business goals, and gaps. We come out with a written scope and recommendation.
Documented architecture, realistic timeline, and transparent commercial proposal. No surprises and no hidden scope.
Configuration, development, integrations, data migration, and QA, with weekly demos and on-the-fly adjustments.
Training, change management, hypercare, and ongoing optimization. We do not disappear at go-live.
Consultant-level analysis from the consultants delivering the work.
How Data 360 and Snowflake share data in both directions without copying it, when to use federation or sharing, practical use cases, cost and governance considerations, and how to plan a first project.
Read the full post →Data 360, formerly Data Cloud, can query Snowflake tables in place through query federation, or read Iceberg-format storage directly through file federation. Salesforce segments, identity resolution and agents can then use warehouse data such as orders or product usage without a nightly copy. Optional cached acceleration keeps a periodically refreshed copy when live queries would be too slow or too frequent.
In the other direction, Data 360 can share unified profiles, calculated insights and segment membership with Snowflake without an export pipeline. Data teams query those objects alongside finance and product tables using ordinary SQL. This matters when analysts want Salesforce’s resolved customer view, rather than raw CRM objects, as the starting point for modeling, forecasting or attribution work in the warehouse.
Snowflake’s Openflow connector uses the Salesforce Bulk API 2.0 to replicate standard and custom objects into Snowflake, one table per object. Incremental loads run on a schedule you set. Deletes arrive as soft deletes, and formula fields can be rebuilt as SQL views. It suits teams that want raw CRM history in the warehouse without licensing Data 360.
Tableau connects to Snowflake through live connections or extracts, and single sign-on can pass each viewer’s identity so Snowflake policies apply. Live connections keep numbers current but run queries on a virtual warehouse whenever someone opens a dashboard. Extracts reduce that load but add refresh schedules. Choosing per data source is one of the biggest levers on both performance and compute consumption.
Snowflake’s governance features, grouped under Horizon, include role-based access, masking policies, row access policies, object tagging and access history. When Salesforce data lands in Snowflake, CRM sharing rules are not enforced there, so these controls must recreate appropriate visibility. Tag personal data at ingestion and apply masking centrally, rather than trusting every downstream report author to filter carefully.
Cortex provides large language model functions and search inside Snowflake, so teams can summarize case notes, classify opportunity loss reasons or search call transcripts using SQL. Run against replicated or shared Salesforce data, it keeps analysis within the warehouse’s governance boundary. Agentforce is the better choice when the AI must act inside Salesforce workflows rather than produce analytical output.
List every direction data must move: Salesforce into Snowflake for analytics, Snowflake into Salesforce or Data 360 for action, and anything shared back. For each flow, record freshness needs, volume and consumers. This inventory tells you whether zero copy, the Openflow connector, another replication tool or a combination fits, and prevents building three pipelines for the same objects.
Land raw Salesforce objects in their own schema, then build cleaned staging and business-ready models on top. Standardize record types, currency and ownership history, and document how each metric is calculated. We keep raw tables untouched so models can be rebuilt when the org changes, which happens every time admins add fields or retire processes.
Create dedicated Snowflake roles and service users for each integration, authenticated with key pairs or OAuth rather than shared passwords. Apply masking and row access policies to sensitive Salesforce fields before any analyst gets access. For Data 360 federation, grant only the schemas Salesforce genuinely needs, and confirm who approves new shares in either direction.
Give ingestion, transformation, BI and Data 360 federation their own virtual warehouses so one workload cannot starve another and costs stay attributable. Set short auto-suspend times, resource monitors and alerts on unusual consumption. Review Data 360 credit usage alongside Snowflake credits, since federated queries can consume capacity on both platforms at once.
Reconcile warehouse totals against Salesforce reports for pipeline, bookings and case counts before publishing dashboards. Monitor connector lag, failed loads and schema changes, and alert owners when a Salesforce field is added or deleted. Hand business users certified data sources rather than raw tables, and review query and credit trends monthly to catch drift early.
Snowflake uses consumption pricing, so cost follows usage rather than seats. Compute is measured in credits: virtual warehouses consume credits per second while running, with larger sizes consuming more, and serverless features and connector runtimes can also draw credits. Storage and cross-region data transfer are billed separately, and your edition affects which governance features are available. Data 360 has its own consumption model, and zero copy queries, acceleration and sharing can draw on both platforms. Confirm with each vendor how federated queries are metered on their side. Tableau licenses are separate again. Ask for usage reporting from day one so credit spend can be tied to specific workloads.
A warehouse with long auto-suspend settings, or one kept awake by frequent dashboard refreshes, consumes credits all day for little work. Oversized warehouses chosen during testing often stay oversized in production. Start small, set brief auto-suspend windows, separate workloads and check which queries actually drive consumption before scaling anything up.
Record-level visibility in Salesforce, built from roles, sharing rules and territories, does not follow data into Snowflake. Analysts may suddenly see every opportunity and every contact’s personal details. Recreate the needed restrictions with row access and masking policies, and review who holds broad roles before connecting Tableau or any other self-service tool.
One team replicates Salesforce with a connector, another exports reports nightly and a third sets up Data 360 federation, each with different definitions. Numbers disagree and costs multiply. Agree on one ingestion path per object, one modeled layer that everyone reads from and a clear owner for changes to either.
A warehouse stores and models data well, but identity resolution, consent handling and real-time activation into Salesforce journeys take significant extra engineering there. Teams sometimes rebuild these capabilities badly. Decide which platform resolves identity and activates audiences, then let the other consume the result through zero copy sharing rather than duplicating logic.
Not always. If the goal is analytics and reporting, Snowflake with a Salesforce connector and a BI tool may be enough. Data 360 earns its place when Salesforce itself must act on unified data, through segments, flows, personalization or Agentforce grounding. With zero copy, the two complement each other: Snowflake stays the analytics store while Data 360 reads what Salesforce needs and shares insights back.
The main options are Snowflake’s Openflow connector using the Salesforce Bulk API, third-party replication tools, MuleSoft or custom pipelines, and Data 360 data sharing. Replication gives you raw object history in warehouse tables. Data 360 sharing gives you unified profiles and calculated insights instead. Many organizations use replication for detailed CRM analytics and sharing for customer-level views, keeping each path clearly documented.
No. Zero copy avoids duplicating storage and building pipelines, but every federated query still runs somewhere. Query federation uses Snowflake compute and Data 360 capacity, while file federation skips Snowflake’s compute layer but still consumes Data 360 processing. Cached acceleration adds refresh work. Model expected query volume up front, place federation on its own warehouse and watch consumption closely during the first months.
Connect to Snowflake when dashboards blend CRM data with other systems, need long history or serve many users, because the warehouse handles joins and volume well. Connect directly to Salesforce for small, CRM-only use cases. With Snowflake, decide between live connections and extracts per data source, since live dashboards with many viewers can keep a warehouse running for most of the day.
Yes, through several routes. Data 360 can federate Snowflake tables and surface the results through segments, data actions or related lists without writing to core objects. When values must land on Salesforce fields, use reverse ETL tooling, MuleSoft or the Bulk API with careful upsert keys. Limit writes to fields reps actually use, and document which system owns each written value.
OpenAI GPT models and the Responses API for production applications and embedded AI features.
Gemini models on Google Vertex AI for enterprise AI deployments and Google Workspace integration.
Copilot Studio, Microsoft 365 Copilot, and Azure OpenAI for Microsoft-first organizations.
Enterprise API platform, for connecting Salesforce, ERP, data warehouses, and the rest of your stack.
Modern iPaaS for SaaS-heavy stacks, automations, recipes, and AI-augmented workflows.
Executive analytics, embedded dashboards, and CRM Analytics built on Tableau.
Tech Talk
A monthly brief for the people who own Salesforce, AI and revenue technology
What changed in Salesforce and AI this month, and what to do about it.
One email a month. Written by the consultants who deliver the work, not by a marketing team, for the leaders who make the technology decisions.
Consultant analysis, not vendor recaps. One click to leave.
