Zero Copy Without Losing Control of Permissions and Data Access

Zero Copy reduces data copies and can make integration architectures significantly leaner. Information does not have to be copied, synchronized, and stored in yet another place for every new analytics, Salesforce, or AI use case. The harder question still remains: Who is allowed to access this data, under which identity does the access happen, and which rules apply when several platforms are involved?

For example, a sales team works in Salesforce while product usage and transaction data live in Databricks. Service needs additional information from a data warehouse, and an Agentforce agent should use selected data to assess an account or prepare a request. Traditionally, this would often require new pipelines and data replication into several systems. Every additional copy brings its own requirements for freshness, permissions, deletion, and governance.

Zero Copy changes this model. Data can remain at its original source and still become usable in other systems. The integration work does not disappear, but partially shifts. Instead of mainly organizing data movement, companies have to define more precisely how identities, permissions, and access rules work across platform boundaries.

What Zero Copy Actually Changes

The term Zero Copy can easily create the impression that data never leaves its original platform at all. Technically, the main point is to avoid building a second permanently replicated data set. With a live query, a request is sent to the source system, processed there, and the required result is returned while the leading data set remains at the source.

Classic ETL or ELT processes deliberately create an additional data set. This copy has to be updated, protected, classified, and, if necessary, deleted again. Changes to permissions or data structures must be replicated cleanly across several platforms, and with time-shifted loading processes, different systems may temporarily work with different data states.

Zero Copy reduces this replication layer. This can be especially interesting for large data sets where the consuming system only needs a small portion of the data. If, for example, billions of usage events live in a data platform but Salesforce only needs aggregated information for individual accounts, the entire data set does not necessarily have to be replicated.

In return, other dependencies arise. The source system must be able to answer the query reliably, permissions must apply correctly on every access, and it must be clear which data may be processed in the consuming system after a query. The technical effort therefore does not disappear completely, but shifts from maintaining additional copies toward access control and runtime behavior.

The technical advantage therefore lies mainly in using data where it is already maintained. Whether this also creates better governance depends on how cleanly the participating permission models are connected.

Permissions Do Not Travel Automatically

If a table is cleanly secured in Databricks or Snowflake, that does not automatically mean Salesforce understands the same users, roles, and business boundaries. Two platforms can know the same person and still use different identifiers, role models, and permission concepts. This is exactly where a technical data connection becomes an architecture question.

Assume an employee may only see customers from their region in the data platform. The same user exists in Salesforce, but access there is controlled through a different role and sharing model. In addition, an agent may access data on behalf of this employee without having the same role as the human user. The architecture then has to traceably represent which usage context actually stands behind a request.

A shared technical service account is relatively easy to set up. However, it can mean that the source system only sees this one technical user and can no longer easily identify which Salesforce user originally triggered the access. If that account is also broadly authorized, restrictions must apply reliably elsewhere.

A user-based or federated identity model enables finer controls, but it requires clean mapping between platforms. Roles, user attributes, offboarding, tokens, and responsibilities become part of the data integration. This may seem more complex at first, but it enables a much more precise implementation of least privilege and auditability.

Zero Copy removes the permanent copy from the architecture. The permissions question remains.

This development is also visible in the collaboration between Salesforce and Databricks. Topics such as federated authentication, identity mapping, and the alignment of governance metadata are moving further into focus. This underlines that Zero Copy does not work in the long term through technical data availability alone, but through a robust connection between data access and identity.

Three Layers of Access Control

With Zero Copy, several governance layers usually work at the same time. The decisive point is therefore not only whether a connection works technically, but also which layer takes on which responsibility and where access is actually limited.

• The data source controls the actual data set. Roles, row-level security, masking, and data classification can already apply in Databricks, Snowflake, or another platform.
• The federated data layer decides which external information becomes available in the Salesforce context and for which use cases it can be used.
• The consumer brings in the concrete usage context. A sales employee, a dashboard, a service team, and an AI agent rarely need the same data and permissions.

These layers should complement each other rather than replace each other. If, for example, the data source already masks sensitive fields, a new access layer should not bypass that restriction. Conversely, Salesforce can set additional boundaries even if the source system would allow broader access.

Problems mainly arise when several layers are supposed to take on the same responsibility and it is not clear which rule is authoritative in case of conflict. A Zero Copy architecture should therefore define early which permissions remain at the source, which rules are added in Salesforce, and how the actual user or process context remains intact throughout.

Why Fewer Copies Can Simplify Governance

The governance advantage of Zero Copy mainly lies in the smaller number of permanently maintained data sets. When sensitive customer data is replicated in several places, there are just as many places where permission changes, deletion rules, classifications, and data quality have to be considered. Every additional platform also expands the area in which governance must be actively managed.

This becomes visible, for example, when an employee changes roles. If access is changed in the leading system, existing copies or downstream systems must also reflect this change promptly. With several pipelines and platforms, exactly this synchronization can become difficult, especially when different teams are responsible for the source, integration, and target system.

In a federated model, the central data set remains closer to its authoritative source. Controls such as row-level security or masking can apply directly there, and changes to these rules take effect on the same source with the next access. This reduces the risk that old copies continue to be used with outdated permissions.

The advantage only materializes, however, if it is clear which rules apply where. If Databricks sets one policy, Salesforce filters additionally, and another consumer uses its own permission logic, the interaction of these layers must remain traceable. Fewer data copies therefore mean fewer governance surfaces, but not automatically less responsibility.

With AI Agents, Access Context Becomes Even More Important

For analytics, Zero Copy is already attractive because current data can be used without constantly maintaining additional pipelines and copies. With Agentforce and other agentic systems, there is an additional factor: agents can combine information from several sources and then use it for further decisions or actions. This increases the value of current data, but also the importance of clearly limited access.

An Agentforce agent could, for example, support an account manager before a contract renewal. Salesforce contains the opportunity, contacts, and previous activities, while product usage and consumption data live in Databricks. The agent should recognize whether usage is declining, whether certain features are barely used, or whether a renewal risk is emerging.

For this task, however, the agent only needs a small excerpt of the entire data set. Access to all customers, historical raw data, or sensitive technical fields would be unnecessary. A good architecture therefore already limits the query and provides only those records and attributes that are needed for the concrete process.

It is also important what happens after the query. Zero Copy prevents a permanent full replication, but the result of a query is still processed and can land in the agent context. Data minimization, logging, and clear rules for permitted agent actions therefore remain relevant.

This shifts the question from "Can the agent access this data?" to "Which data does the agent need for exactly this task?". This distinction is essential because productive agents can, over time, access more and more systems and data sources. A technically possible access path should therefore not automatically become a business-approved access path.

Zero Copy, Ingestion, or Caching?

Zero Copy should not automatically be the preferred solution for every data set. In a real enterprise architecture, different models can make sense in parallel because requirements for freshness, performance, cost, and governance vary significantly.

Zero Copy or federation is especially suitable for large, current, and already well-controlled data sets where an additional full copy would add little value. This applies, for example, to extensive usage, transaction, or event data from which Salesforce only needs specific excerpts.

Ingestion can make sense when data is processed intensively inside Data 360, needed for Identity Resolution, or tightly embedded in operational Salesforce processes. In such cases, a deliberately created data set inside the platform can be easier to process and govern.

Caching can help with frequent live queries by reducing latency and load on the source system. In return, temporary data is again created outside the original platform, which must be considered for governance and compliance requirements.

In practice, this often results in a hybrid model. A stable core is ingested, large or especially current external data sets remain federated, and frequently needed information is selectively accelerated. The better architecture is not the one with the highest Zero Copy share, but the one that supports the respective use case with as little unnecessary data movement as possible.

A Sales Example

A software company manages accounts, opportunities, and contacts in Salesforce. Product usage data lives in Databricks, where the data team prepares, classifies, and controls it through existing governance rules. Sales wants to see current usage information directly in the account context, while an Agentforce agent should detect possible drops in usage before contract renewals and provide relevant guidance to the account manager.

Fully replicating all historical usage data into Salesforce would be unnecessary. A large share of these events would never be needed in the sales process, but would still have to be stored, synchronized, and secured. With Zero Copy, the relevant information can instead become available in the Salesforce context while the leading data set remains in Databricks.

The account manager should only see the accounts they are responsible for. The agent also only needs the data relevant to its concrete use case. Sensitive fields can already remain excluded or masked at the source, while additional rules in the Salesforce context further restrict access.

For governance, it is also important that the request path remains traceable. Ideally, it should later be possible to see which user or agent queried the data, under which identity the access was executed, and in which process context the information was used.

The value therefore comes from two components: current data without an additional full replication, and an access model that respects existing governance rules. This is exactly the difference between a technically working Zero Copy connection and a robust enterprise architecture.

What Companies Should Clarify Before Implementation

Before a Zero Copy connection is implemented, four architecture-level decisions should already be made. If they are only clarified after the technical connection is in place, the access model often has to be rebuilt later with additional effort.

1. Where does the leading permission logic live? Existing row-level security, masking, and business access rules should not be bypassed by the new access layer. It must be clear which rules remain at the source and where additional restrictions are necessary.

2. Under which identity is the query executed? Technical accounts and user-based identities have different implications for least privilege and auditability. Especially with agents, it should remain traceable on whose behalf an access took place.

3. Which data does the concrete consumer need? A dashboard, a sales employee, and an AI agent rarely need the same data scope. Records and fields should therefore be aligned with the actual use case.

4. How does access remain traceable? For sensitive processes, it should be visible which user or agent queried which information, which permissions applied, and in which process context this happened.

These decisions may look organizational, but they are direct technical architecture questions. When they are clarified early, Zero Copy can be integrated much more cleanly into an existing data and permission landscape.

What Matters Now

Zero Copy can simplify data architectures because full data sets do not have to be copied and synchronized every time for new Salesforce, analytics, or AI use cases. The benefit only remains, however, when identity, permissions, and governance are planned as deliberately as the technical connection.

For us at Ai11, Zero Copy therefore belongs in the data and integration architecture. The decisive question is not only where data lives, but who may use it in which context and how this access remains traceable.

You would like to assess which data in your architecture can sensibly be federated and how permissions can remain controllable? Contact us.