A lot of companies asking about Data 360 already have a data warehouse: Snowflake, Databricks, BigQuery or Redshift, with a team that runs it. The fair question is whether Salesforce needs its own data platform on top of that, or whether a sync from the warehouse is enough.
Short answer: if the warehouse already knows who each customer is and Salesforce only needs a few fields or scores on the record, sync them or use zero copy and skip the rest. Data 360 earns its cost when you need identity resolution, segments or agent grounding inside Salesforce, things a sync doesn't give you.
What a Warehouse Sync Does Well
A sync, usually called reverse ETL, pushes data from the warehouse into Salesforce fields on a schedule: a lifetime value score on the Account, a churn flag on the Contact, product usage on the Opportunity.
It's the right call when:
- The warehouse already resolves identity. Your data team has one customer ID and the matching logic to go with it.
- Salesforce only needs to display it. Reps need to see a number or a flag on the record, not build segments from it.
- The volume is modest. A handful of fields on a few objects, refreshed daily.
- Your data team owns the logic. Calculations live where your analysts already work and test them.
It's cheap, it's simple, and the people who own the data keep owning it.
Where Data 360 Earns Its Cost
Identity resolution inside Salesforce. When the same person exists as several Contacts, a Lead and a record in another system, Data 360 links them into one profile using match rules you control. On a recent Contact 360 build, the master data system's IDs drove the matching, with email as a tightened fallback.
Segments and activation. If marketing builds audiences from combined CRM, product and engagement data and sends them to campaigns, that's Data 360's core job.
Agent grounding. Agentforce can ground on the unified profile and on unstructured content like Knowledge articles. If agents are on the roadmap, the data model you build now is the one they'll read.
Calculated insights next to the record. Metrics computed across sources and shown in Sales or Service Cloud, without writing them back into fields on every object.
Zero Copy Changes the Math
Data 360 doesn't have to copy everything. With zero copy federation, it can query tables that stay in Snowflake, Databricks, BigQuery or Redshift. Where you do need data inside Data 360, the warehouse connectors bring it in directly. On the Contact 360 project, meeting notes and attendee data came in through the Databricks connector, set up and tested in a sandbox first.
That means the choice isn't always all or nothing. A common shape is to keep analytics and heavy transforms in the warehouse, federate the tables Salesforce needs, and use Data 360 only for identity, segments and grounding.
The Cost Trap to Avoid
Data 360 bills on consumption, so the biggest cost mistake is ingesting everything because the diagram looks thorough. Every stream you add is another refresh to pay for and maintain.
The rule I use: if a record already lives in Salesforce and the page can query it, don't ingest it just to read it back. Ingest what identity resolution needs, federate what you can, and read the rest live.
How to Decide
- Does the warehouse already resolve each customer to one ID?
- Does Salesforce need to show the data, or build segments and decisions from it?
- Will agents need to ground on this data?
- Who should own the matching logic, your data team or your Salesforce team?
- Which tables could stay in the warehouse and be federated?
If the warehouse resolves identity and Salesforce only needs to display a few values, start with a sync. If you need one profile, segments or agent grounding inside Salesforce, that's Data 360.
Want a second opinion on your setup? Book a call. More on how I run these projects on the Data Cloud consulting page.