Zero Copy klingt zunächst nach einer sehr einfachen Antwort auf ein bekanntes Datenproblem. Daten müssen nicht mehr mehrfach kopiert, synchronisiert und in verschiedenen Systemen aktuell gehalten werden. Salesforce Data 360 kann externe Datenquellen wie Databricks einbinden, ohne dass die Daten dafür vollständig in Salesforce repliziert werden müssen. Salesforce beschreibt Zero Copy als Federation-Technologie, mit der Unternehmen Daten abfragen und verwenden können, ohne sie zu kopieren.
Das ist gerade für moderne Datenarchitekturen relevant. Kundendaten liegen im CRM, Produktnutzung im Lakehouse, Serviceinformationen in weiteren Plattformen und operative Ereignisse in spezialisierten Systemen. Wenn diese Daten für Profile, Segmentierung, Analytics oder Agentenprozesse verfügbar werden sollen, wirkt Zero Copy wie der direkte Weg: weniger ETL, weniger Duplikate, weniger technische Reibung.
Die entscheidende Frage verschwindet dadurch aber nicht. Wer darf welche Daten sehen? Welche Berechtigung gilt, wenn ein CRM-Prozess auf Databricks-Daten zugreift? Welche Metadaten bleiben erhalten? Und wie lässt sich später nachvollziehen, warum eine bestimmte Information in Data 360, Agentforce oder einer Analyse verwendet wurde?
Zero Copy reduziert Datenbewegung. Es ersetzt keine Zugriffsstrategie.
Weniger Kopien bedeuten nicht automatisch mehr Kontrolle. Kontrolle entsteht erst dann, wenn Identität, Berechtigung, Zweck und Herkunft auch beim föderierten Zugriff klar bleiben.
Warum Zero Copy gerade relevanter wird
Salesforce positioniert Data 360 Zero Copy als Möglichkeit, Unternehmensdaten in Anwendungen, Analysen und agentischen Prozessen verfügbar zu machen, ohne sie klassisch zu verschieben. Die Plattform beschreibt unter anderem Live Query, Cached Acceleration sowie bidirektionale Zero-Copy-Szenarien zwischen Data 360 und externen Datenplattformen.
Auch die Partnerschaft mit Databricks zeigt diese Richtung. Salesforce hat im Juni 2026 angekündigt, gemeinsam mit Databricks an einer gemeinsamen Datenbasis für Menschen und AI Agents zu arbeiten. Foundational Data 360 Zero Copy Capabilities und MuleSoft Agent Scanner for Databricks sind laut Salesforce bereits allgemein verfügbar, weitere Data-360-Erweiterungen sind für H2 2026 und darüber hinaus geplant.
Der Business-Nutzen ist nachvollziehbar. Wenn aktuelle Daten aus dem Lakehouse in CRM-nahe Prozesse einfließen können, werden Entscheidungen näher an der operativen Realität getroffen. Ein Service-Team kann etwa aktuelle Produktnutzung berücksichtigen, ein Vertriebsteam kann Segmentierungsdaten einbeziehen und ein Agent kann Antworten mit Informationen aus mehreren Systemen anreichern.
Genau dadurch steigt aber auch die Verantwortung. Daten werden nicht weniger sensibel, nur weil sie nicht kopiert werden. Sie werden an mehr Stellen wirksam.
Datenzugriff ist mehr als eine technische Verbindung
Bei klassischen Integrationen ist oft klar, wo eine Kopie entsteht. Daten werden aus System A exportiert, transformiert, in System B geladen und dort mit eigenen Berechtigungen, Modellen und Aufbewahrungsregeln verwaltet. Das ist aufwendig und erzeugt neue Risiken, macht die Verantwortungsgrenzen aber häufig sichtbar.
Bei Zero Copy verschiebt sich diese Grenze. Das Zielsystem arbeitet mit Daten, die physisch weiterhin an anderer Stelle liegen. Technisch ist das effizienter. Organisatorisch wird aber wichtiger, welche Regeln beim Zugriff gelten.
Ein CRM-Anwender sieht vielleicht nur ein berechnetes Merkmal im Kundenprofil. Dahinter kann eine Abfrage auf Databricks-Daten stehen, die über eine Verbindung, einen Service Principal, eine Federation Policy und Berechtigungen im Lakehouse gesteuert wird. Der Anwender sieht nicht zwingend, welche technische Identität den Zugriff ermöglicht hat und welche Datenbasis dafür abgefragt wurde.
Damit entsteht ein neues Zusammenspiel aus Plattformberechtigungen, Datenplattform-Governance und fachlichem Zweck. Genau dort entscheidet sich, ob Zero Copy wirklich kontrolliert eingesetzt wird.
Was beim Databricks-Zugriff technisch passiert
Databricks beschreibt für Salesforce Data 360 mehrere Connector-Optionen. Zwei davon sind Zero-Copy-Connectoren: Salesforce Data 360 File Sharing und Salesforce Data 360 Query Federation. Beide erlauben laut Databricks Abfragen von Salesforce-Data-360-Daten, ohne diese zu bewegen. Zusätzlich gibt es einen Salesforce-Ingestion-Connector, der Daten tatsächlich kopiert.
Der Unterschied ist wichtig. Bei Query Federation verbindet sich Databricks über JDBC mit Salesforce und pusht Abfragen in die Quelle. Bei File Sharing liest Databricks über Salesforce Data-as-a-Service APIs direkt aus der zugrunde liegenden Cloud-Object-Storage-Location. Databricks beschreibt File Sharing insbesondere für größere Datenmengen und bessere Pushdown-Möglichkeiten.
Für die Governance ist außerdem relevant, wie der Zugriff in Databricks abgebildet wird. Databricks erstellt im Rahmen der Lakehouse Federation eine Connection und einen Foreign Catalog, der die Salesforce-Data-360-Datenbank in Unity Catalog spiegelt. Dadurch können Databricks-Nutzer mit Unity-Catalog-Abfragesyntax arbeiten und Databricks-Governance-Werkzeuge für den Zugriff verwenden.
Auf Salesforce-Seite braucht die Einrichtung einer Databricks Data Federation Connection entsprechende Berechtigungen. In der Data-360-Dokumentation werden dafür unter anderem das System Admin Profile oder das Data Cloud Architect Permission Set genannt. Außerdem müssen IP-Allowlists, Databricks-Runtime-Anforderungen, SQL-Warehouse- oder Cluster-Voraussetzungen und Authentifizierungsmethoden berücksichtigt werden.
Das zeigt: Zero Copy ist kein reines Feature im Datenmodell. Es ist eine Verbindung zwischen mehreren Kontrollschichten.
Wo Kontrolle verloren gehen kann
Zero Copy löst ein Problem, schafft aber neue Prüfstellen. Besonders kritisch wird es, wenn technische Verbindung, fachliche Berechtigung und Datenverwendung getrennt betrachtet werden.
| Kontrollpunkt | Zentrale Frage | Risiko bei unklarer Regelung |
|---|---|---|
| Identität | Welche technische oder fachliche Identität führt den Zugriff aus? | Ein Service Principal erhält mehr Zugriff als der eigentliche Use Case benötigt |
| Berechtigung | Welche Daten darf diese Identität lesen, schreiben oder ableiten? | Daten werden in Data 360 oder Analytics sichtbar, obwohl sie im Ursprung enger geschützt sind |
| Zweckbindung | Für welchen Prozess oder welche Anwendung wird der Zugriff eingerichtet? | Eine Verbindung wird später für weitere Use Cases verwendet, ohne neue Bewertung |
| Metadaten | Welche Herkunft, Aktualität und Bedeutung der Daten bleiben sichtbar? | Nutzer sehen ein Feld, aber nicht, woher es kommt oder wie aktuell es ist |
| Auditierbarkeit | Welche Abfrage, Anwendung oder Aktion hat den Zugriff ausgelöst? | Fehler oder unerwünschte Nutzung lassen sich später schwer nachvollziehen |
Diese Punkte sind nicht neu. Sie werden aber wichtiger, wenn Daten über Plattformgrenzen hinweg direkt verwendbar werden. Eine Kopie ist sichtbar, weil sie Speicher, Pipeline und Zielmodell braucht. Ein föderierter Zugriff kann leichter wie eine normale Abfrage wirken, obwohl er fachlich dieselbe Relevanz hat.
Zero Copy entfernt die Kopie, aber nicht die Verantwortung. Jede Abfrage braucht weiterhin eine Identität, einen Zweck und eine nachvollziehbare Grenze.
Berechtigungen müssen mit dem Kontext reisen
Ein häufiger Denkfehler bei föderierten Architekturen ist die Annahme, dass Berechtigungen automatisch im richtigen Fachkontext ankommen. Technisch gibt es eine Verbindung, also scheint der Zugriff geregelt zu sein. Für produktive Unternehmensprozesse reicht das nicht.
Ein Service Principal in Databricks kann technisch Zugriff auf bestimmte Tabellen haben. Daraus folgt aber noch nicht, dass jeder CRM-Prozess diese Daten in jedem Kontext verwenden sollte. Ein Sales-Team benötigt andere Informationen als ein Service-Team. Ein Agent, der eine Kundenfrage beantwortet, braucht andere Daten als ein Analyst, der ein Segmentierungsmodell erstellt.
Die Salesforce-Dokumentation zur Data-360-Verbindung mit Databricks zeigt, dass Verbindungen über Authentifizierungsmethoden, Connection URLs, HTTP Paths und Berechtigungen eingerichtet werden. Im IDP-basierten Setup beschreibt Salesforce außerdem Service Principals, Federation Policies und die Vergabe von Zugriff auf SQL Warehouses und Kataloge.
Das sind notwendige technische Kontrollen. Fachlich muss zusätzlich geklärt werden, welche Nutzung durch diese Verbindung erlaubt ist. Sonst wird aus einer sauber eingerichteten Connection schnell ein breit verwendeter Datenzugang.
Zero Copy und Agenten erhöhen den Anspruch
Die Diskussion wird noch wichtiger, wenn nicht nur Menschen auf föderierte Daten zugreifen, sondern auch Agenten. Salesforce beschreibt Data 360 Zero Copy ausdrücklich als Grundlage, um strukturierte und unstrukturierte Unternehmensdaten für Agentforce und andere AI-basierte Erfahrungen verfügbar zu machen.
Ein Agent fragt Daten nicht wie ein klassischer Report ab. Er nutzt sie, um Antworten zu formulieren, nächste Schritte vorzuschlagen oder Aktionen vorzubereiten. Dadurch verändert sich die Wirkung einer Berechtigung. Eine Information wird nicht nur angezeigt, sondern kann in eine Entscheidung oder Handlung einfließen.
Wenn ein Agent etwa Produktnutzung aus Databricks, Vertragsstatus aus Salesforce und Servicehistorie aus einem weiteren System kombiniert, muss klar sein, welche Quelle für welche Aussage maßgeblich ist. Ebenso muss nachvollziehbar bleiben, ob der Agent nur Kontext gelesen, eine Empfehlung abgeleitet oder eine konkrete Änderung vorbereitet hat.
In solchen Szenarien reicht es nicht, Daten allgemein verfügbar zu machen. Der Zugriff muss pro Use Case, Rolle und Aktion bewertet werden.
Welche Regeln vor der Umsetzung geklärt sein sollten
Vor einer Zero-Copy-Umsetzung sollten Unternehmen nicht nur die Verbindung planen, sondern auch die Betriebslogik dahinter. Besonders wichtig sind folgende Fragen:
-
Welche Daten bleiben im Ursprung führend? Zero Copy bedeutet nicht, dass Data 360, Databricks oder eine Anwendung automatisch zum neuen System of Record werden. Für jedes kritische Feld sollte klar sein, welches System die verbindliche Quelle bleibt.
-
Welche Identität greift in welchem Kontext zu? Service Principals, technische Benutzer und Plattformrollen müssen so geschnitten sein, dass sie zum jeweiligen Use Case passen. Eine breit berechtigte Verbindung sollte nicht mehrere fachlich unterschiedliche Prozesse ungeprüft bedienen.
-
Welche Metadaten müssen sichtbar bleiben? Herkunft, Aktualität, Qualitätsstatus und Zweck der Daten sollten nicht im technischen Zugriff verschwinden. Sonst wird eine föderierte Information im Zielsystem schnell wie ein lokaler Fakt behandelt.
-
Welche Nutzung wird protokolliert? Bei Reporting reicht oft die Abfragehistorie. Bei Agentenprozessen muss zusätzlich sichtbar bleiben, welche Antwort, Empfehlung oder Aktion durch welche Daten beeinflusst wurde.
Diese Fragen sind kein Ersatz für die technische Einrichtung. Sie bestimmen, ob die technische Einrichtung später kontrollierbar bleibt.
Wann eine Kopie trotzdem sinnvoll sein kann
Zero Copy ist nicht automatisch die beste Antwort für jeden Datenbedarf. Salesforce weist selbst darauf hin, dass je nach Datenvolumen und Geschwindigkeit manchmal eine physische Kopie sinnvoller sein kann. Data 360 bietet deshalb neben Live Query auch Cached Acceleration, bei der externe Daten temporär gecached und regelmäßig inkrementell aktualisiert werden können.
Das ist ein wichtiger Punkt. Es gibt Szenarien, in denen Performance, Kosten, Verfügbarkeit oder Berechnungslogik gegen eine rein föderierte Abfrage sprechen. Ein häufig genutztes Segment, ein stark belasteter Serviceprozess oder eine komplexe Transformation kann mit Caching oder gezielter Replikation stabiler betrieben werden.
Die Architekturfrage lautet daher nicht: Kopieren oder nie kopieren. Sie lautet: Welche Daten müssen live gelesen werden, welche dürfen gecached werden und welche gehören bewusst in ein führendes System überführt?
Zero Copy ist ein Werkzeug im Datenarchitektur-Baukasten. Es sollte nicht zum Dogma werden.
Gute Datenarchitektur misst sich nicht daran, ob keine Kopie existiert. Sie misst sich daran, ob Aktualität, Zugriff, Kosten und Verantwortung zum jeweiligen Prozess passen.
Was Unternehmen jetzt prüfen sollten
Für Unternehmen, die Salesforce Data 360 und Databricks gemeinsam einsetzen oder vorbereiten, ist Zero Copy ein guter Anlass für eine präzise Bestandsaufnahme. Nicht jedes Projekt braucht sofort ein vollständiges Governance-Programm. Aber jede produktive Verbindung braucht klare Zuständigkeiten.
Praktisch beginnt das mit wenigen konkreten Punkten:
- Welche Data-360- und Databricks-Verbindungen existieren bereits oder sind geplant?
- Welche Tabellen, Objekte und Felder werden über Federation verfügbar gemacht?
- Welche technische Identität wird verwendet und wer verantwortet sie?
- Welche Rollen oder Prozesse dürfen die Daten tatsächlich verwenden?
- Wie werden Abfragen, Agentenaktionen und Änderungen später nachvollzogen?
Diese Prüfung verhindert, dass Zero Copy nur als schnellere Verbindung verstanden wird. Sie macht sichtbar, welche Datenflüsse dadurch in Geschäftsprozessen, Analysen und agentischen Anwendungen wirksam werden.
Was jetzt zählt
Zero Copy ist ein starker Schritt für Datenintegration. Es reduziert unnötige Datenbewegung, macht aktuelle Informationen schneller verfügbar und kann Salesforce-Prozesse enger mit Lakehouse-Daten verbinden. Besonders mit Databricks zeigt sich, wie CRM, Data 360 und analytische Plattformen näher zusammenrücken.
Der entscheidende Punkt bleibt aber Kontrolle. Daten, die nicht kopiert werden, sind nicht automatisch besser geschützt. Sie werden nur anders zugänglich. Genau deshalb müssen Identität, Berechtigung, Zweckbindung, Metadaten und Auditierbarkeit von Anfang an mitgedacht werden.
Zero Copy ohne Governance verschiebt das Problem. Zero Copy mit klaren Zugriffen, nachvollziehbaren Quellen und sauberer Zuständigkeit kann dagegen genau das leisten, was moderne Datenarchitekturen brauchen: aktuelle Daten dort verfügbar machen, wo sie gebraucht werden, ohne die Kontrolle über ihre Verwendung zu verlieren.