At first, Zero Copy sounds like a very simple answer to a familiar data problem. Data no longer has to be copied multiple times, synchronised, and kept current across different systems. Salesforce Data 360 can bring in external data sources such as Databricks without the data having to be fully replicated into Salesforce. Salesforce describes Zero Copy as a federation technology that lets companies query and use data without copying it.
This is particularly relevant for modern data architectures. Customer data lives in the CRM, product usage in the lakehouse, service information on further platforms, and operational events in specialised systems. When this data is to become available for profiles, segmentation, analytics, or agent processes, Zero Copy looks like the direct route: less ETL, fewer duplicates, less technical friction.
The decisive question, however, does not disappear. Who may see which data? Which permission applies when a CRM process accesses Databricks data? Which metadata is preserved? And how can you later reconstruct why a particular piece of information was used in Data 360, Agentforce, or an analysis?
Zero Copy reduces data movement. It does not replace an access strategy.
Fewer copies do not automatically mean more control. Control only emerges when identity, permission, purpose, and provenance remain clear even with federated access.
Why Zero Copy is becoming more relevant now
Salesforce positions Data 360 Zero Copy as a way to make enterprise data available in applications, analytics, and agentic processes without moving it in the classic sense. The platform describes, among other things, Live Query, Cached Acceleration, and bidirectional Zero Copy scenarios between Data 360 and external data platforms.
The partnership with Databricks points in the same direction. In June 2026, Salesforce announced that it would work with Databricks on a shared foundation of data for people and AI agents. According to Salesforce, foundational Data 360 Zero Copy capabilities and the MuleSoft Agent Scanner for Databricks are already generally available, with further Data 360 extensions planned for H2 2026 and beyond.
The business value is easy to follow. When current data from the lakehouse can flow into CRM-adjacent processes, decisions are made closer to operational reality. A service team can factor in current product usage, a sales team can bring in segmentation data, and an agent can enrich responses with information from several systems.
But that is exactly what increases the responsibility. Data does not become less sensitive just because it is not copied. It takes effect in more places.
Data access is more than a technical connection
With classic integrations, it is often clear where a copy is created. Data is exported from system A, transformed, loaded into system B, and managed there with its own permissions, models, and retention rules. That is laborious and creates new risks, but it usually makes the boundaries of responsibility visible.
With Zero Copy, that boundary shifts. The target system works with data that physically still resides elsewhere. Technically, that is more efficient. Organisationally, what matters more is which rules apply on access.
A CRM user may only see a computed attribute in the customer profile. Behind it there can be a query against Databricks data, governed by a connection, a service principal, a federation policy, and permissions in the lakehouse. The user does not necessarily see which technical identity enabled the access and which data basis was queried for it.
This creates a new interplay of platform permissions, data-platform governance, and business purpose. That is exactly where it is decided whether Zero Copy is really used in a controlled way.
What technically happens on Databricks access
For Salesforce Data 360, Databricks describes several connector options. Two of them are Zero Copy connectors: Salesforce Data 360 File Sharing and Salesforce Data 360 Query Federation. According to Databricks, both allow querying Salesforce Data 360 data without moving it. In addition, there is a Salesforce ingestion connector that does actually copy data.
The difference matters. With Query Federation, Databricks connects to Salesforce via JDBC and pushes queries into the source. With File Sharing, Databricks reads directly from the underlying cloud object storage location via Salesforce Data-as-a-Service APIs. Databricks describes File Sharing in particular for larger data volumes and better pushdown capabilities.
For governance, it also matters how the access is represented in Databricks. As part of Lakehouse Federation, Databricks creates a connection and a foreign catalog that mirrors the Salesforce Data 360 database in Unity Catalog. This lets Databricks users work with Unity Catalog query syntax and use Databricks governance tooling for the access.
On the Salesforce side, setting up a Databricks data federation connection requires the corresponding permissions. The Data 360 documentation names, among others, the System Admin profile or the Data Cloud Architect permission set for this. In addition, IP allowlists, Databricks runtime requirements, SQL warehouse or cluster prerequisites, and authentication methods have to be considered.
This shows: Zero Copy is not a pure feature in the data model. It is a connection between several control layers.
Where control can be lost
Zero Copy solves one problem but creates new checkpoints. It becomes especially critical when the technical connection, the business permission, and the data usage are considered separately.
| Control point | Central question | Risk with unclear rules |
|---|---|---|
| Identity | Which technical or business identity performs the access? | A service principal receives more access than the actual use case requires |
| Permission | Which data may this identity read, write, or derive? | Data becomes visible in Data 360 or analytics even though it is more tightly protected at source |
| Purpose binding | For which process or application is the access set up? | A connection is later used for further use cases without a new assessment |
| Metadata | Which provenance, timeliness, and meaning of the data stays visible? | Users see a field but not where it comes from or how current it is |
| Auditability | Which query, application, or action triggered the access? | Errors or unwanted use are hard to reconstruct later |
These points are not new. But they become more important when data becomes directly usable across platform boundaries. A copy is visible, because it needs storage, a pipeline, and a target model. A federated access can more easily look like a normal query, even though it carries the same relevance in business terms.
Zero Copy removes the copy, but not the responsibility. Every query still needs an identity, a purpose, and a traceable boundary.
Permissions have to travel with the context
A common mistake with federated architectures is the assumption that permissions automatically arrive in the right business context. There is a technical connection, so the access appears to be governed. For production enterprise processes, that is not enough.
A service principal in Databricks can technically have access to certain tables. But it does not follow that every CRM process should use this data in every context. A sales team needs different information than a service team. An agent answering a customer question needs different data than an analyst building a segmentation model.
The Salesforce documentation for the Data 360 connection with Databricks shows that connections are set up via authentication methods, connection URLs, HTTP paths, and permissions. In the IDP-based setup, Salesforce additionally describes service principals, federation policies, and granting access to SQL warehouses and catalogs.
These are necessary technical controls. In business terms, it additionally has to be clarified which use is permitted through this connection. Otherwise a cleanly set-up connection quickly becomes a broadly used data gateway.
Zero Copy and agents raise the bar
The discussion becomes even more important when it is not only humans accessing federated data, but also agents. Salesforce explicitly describes Data 360 Zero Copy as a foundation for making structured and unstructured enterprise data available for Agentforce and other AI-based experiences.
An agent does not query data like a classic report. It uses it to formulate answers, propose next steps, or prepare actions. This changes the effect of a permission. A piece of information is not only displayed, but can flow into a decision or an action.
If an agent combines, say, product usage from Databricks, contract status from Salesforce, and service history from another system, it has to be clear which source is authoritative for which statement. It also has to remain traceable whether the agent only read context, derived a recommendation, or prepared a concrete change.
In such scenarios, it is not enough to make data generally available. Access has to be assessed per use case, role, and action.
Which rules should be settled before implementation
Before a Zero Copy implementation, companies should plan not only the connection, but also the operating logic behind it. The following questions are especially important:
-
Which data remains authoritative at source? Zero Copy does not mean that Data 360, Databricks, or an application automatically becomes the new system of record. For every critical field, it should be clear which system remains the binding source.
-
Which identity accesses in which context? Service principals, technical users, and platform roles have to be cut so that they fit the respective use case. A broadly permissioned connection should not serve several functionally distinct processes unchecked.
-
Which metadata has to remain visible? Provenance, timeliness, quality status, and purpose of the data should not disappear in the technical access. Otherwise a federated piece of information is quickly treated like a local fact in the target system.
-
Which usage is logged? For reporting, the query history is often enough. For agent processes, it additionally has to remain visible which answer, recommendation, or action was influenced by which data.
These questions are not a substitute for the technical setup. They determine whether the technical setup remains controllable later.
When a copy can still make sense
Zero Copy is not automatically the best answer for every data need. Salesforce itself points out that, depending on data volume and speed, a physical copy can sometimes make more sense. That is why Data 360 offers, alongside Live Query, also Cached Acceleration, where external data can be temporarily cached and regularly updated incrementally.
That is an important point. There are scenarios in which performance, cost, availability, or computation logic argue against a purely federated query. A frequently used segment, a heavily loaded service process, or a complex transformation can be operated more stably with caching or targeted replication.
The architecture question is therefore not: copy or never copy. It is: which data has to be read live, which may be cached, and which deliberately belongs in a leading system?
Zero Copy is a tool in the data-architecture toolbox. It should not become a dogma.
Good data architecture is not measured by whether no copy exists. It is measured by whether timeliness, access, cost, and responsibility fit the respective process.
What companies should review now
For companies that use Salesforce Data 360 and Databricks together, or are preparing to, Zero Copy is a good occasion for a precise inventory. Not every project needs a full governance programme right away. But every production connection needs clear ownership.
In practice, this starts with a few concrete points:
- Which Data 360 and Databricks connections already exist or are planned?
- Which tables, objects, and fields are made available via federation?
- Which technical identity is used, and who is accountable for it?
- Which roles or processes may actually use the data?
- How are queries, agent actions, and changes reconstructed later?
This review prevents Zero Copy from being understood merely as a faster connection. It makes visible which data flows thereby take effect in business processes, analytics, and agentic applications.
What matters now
Zero Copy is a strong step for data integration. It reduces unnecessary data movement, makes current information available faster, and can connect Salesforce processes more closely with lakehouse data. With Databricks in particular, it shows how CRM, Data 360, and analytical platforms move closer together.
The decisive point, however, remains control. Data that is not copied is not automatically better protected. It just becomes accessible differently. That is exactly why identity, permission, purpose binding, metadata, and auditability have to be considered from the start.
Zero Copy without governance shifts the problem. Zero Copy with clear access, traceable sources, and clean ownership can deliver exactly what modern data architectures need: making current data available where it is needed, without losing control over how it is used.