Salesforce Commerce Cloud Deep Dive
Architektur, Unified Commerce und Agentforce im Realitätscheck
Andreas RiegerSalesforce Commerce Cloud gehört zu den etablierten Enterprise-Commerce-Lösungen für Unternehmen mit komplexen Handelsprozessen, internationalen Geschäftsmodellen und umfangreichen Anforderungen an die Verbindung von Commerce, Kundenmanagement und Service.
Dabei wird die Plattform häufig als Teil einer integrierten Salesforce-Landschaft betrachtet. Das ist nachvollziehbar. Salesforce bietet ein breites Portfolio für digitalen Handel, stationären Verkauf, Auftragsmanagement, Kundendaten und zunehmend auch KI-gestützte Geschäftsprozesse.
Die tatsächliche Architektur ist jedoch differenzierter, als die gemeinsame Produktbezeichnung zunächst vermuten lässt.
B2C Commerce und B2B Commerce stammen aus unterschiedlichen technologischen Entwicklungen. Weitere Produkte für Order Management, Point of Sale, Payments und Datenintegration ergänzen das Portfolio. Mit Agentforce entsteht darüber hinaus eine neue Ebene, auf der KI-Agenten Informationen auswerten und Geschäftsprozesse unterstützen oder auslösen können.
Diese Entwicklung erweitert die Möglichkeiten der Plattform. Sie verändert aber nicht automatisch ihre technischen Grundlagen.
Die entscheidende Frage lautet deshalb nicht, wie viele Salesforce-Produkte miteinander verbunden werden können. Entscheidend ist, welche Geschäftsprozesse tatsächlich durchgängig funktionieren, welche Voraussetzungen dafür geschaffen werden müssen und wie viel technische und wirtschaftliche Abhängigkeit daraus entsteht.
Dieser Deep Dive untersucht Salesforce Commerce Cloud aus dieser Perspektive. Herstellerangaben werden von dokumentierten Produktfähigkeiten und unabhängigen Schlussfolgerungen unterschieden. Es gibt keine numerische Bewertung und keine pauschale Plattformempfehlung.
1. Executive Summary: Eine Plattform, mehrere technische Realitäten
Salesforce Commerce Cloud ist weniger als einzelnes Commerce-System zu verstehen denn als Portfolio aus unterschiedlichen Handelsanwendungen und ergänzenden Plattformdiensten.
Die B2C-Lösung basiert auf der früheren Demandware-Technologie und verfügt über einen eigenen Commerce-Kern, ein etabliertes SaaS-Betriebsmodell und verschiedene Ansätze zur Storefront-Entwicklung.
B2B Commerce ist dagegen historisch aus CloudCraze hervorgegangen und stärker mit dem Salesforce-Datenmodell und den Anwendungsmöglichkeiten der Salesforce Platform verbunden.
Diese Unterscheidung bleibt wesentlich, auch wenn Salesforce beide Bereiche unter einer gemeinsamen Produktfamilie vermarktet und zunehmend gemeinsame Dienste bereitstellt.
Für Unternehmen mit einer bestehenden Salesforce-Landschaft kann die Verbindung von Commerce, Kundeninformationen, Vertrieb und Service erhebliche Vorteile eröffnen. Sie kann den Zugriff auf Kundenkontext vereinfachen und neue Möglichkeiten für die Steuerung kanalübergreifender Prozesse schaffen.
Die Zugehörigkeit zum selben Hersteller macht die Integration allerdings nicht automatisch einfach. Auch innerhalb des Salesforce-Portfolios müssen Datenmodelle, Berechtigungen, Systemverantwortlichkeiten und Prozessabläufe aufeinander abgestimmt werden.
Bei Unified Commerce zeigt sich diese Spannung besonders deutlich. Salesforce verfügt inzwischen über eigene Lösungen für Point of Sale, Order Management und Bestandsprozesse. Damit sind wichtige Komponenten einer kanalübergreifenden Handelsarchitektur verfügbar.
Ob ein Händler tatsächlich über konsistente Bestände, gemeinsame Kundenidentitäten und kanalübergreifende Auftrags- und Retourenprozesse verfügt, hängt von der jeweiligen Implementierung ab.
Eine gemeinsame Kundensicht ersetzt kein einheitliches Bestandsmodell. Ein angebundenes Order Management garantiert noch keine konsistenten Liefer- und Retourenprozesse.
Mit Agentforce gewinnt diese Unterscheidung zusätzliche Bedeutung.
Salesforce bietet inzwischen allgemein verfügbare Agentenprodukte für Shopping, B2B-Beschaffung und Merchandising. Gleichzeitig entwickelt das Unternehmen Integrationen für externe KI-Systeme und offene Commerce-Protokolle.
Die technische Reife dieser Angebote unterscheidet sich jedoch erheblich.
Während bestimmte Funktionen produktiv verfügbar sind, befinden sich andere noch im Pilotbetrieb oder unterliegen Einschränkungen hinsichtlich Sprache, Region, Edition und Vertriebskanal.
Besonders relevant ist die Unterscheidung zwischen KI-gestützter Produktberatung und einer tatsächlich ausgeführten Transaktion. Ein Agent, der Produkte empfiehlt oder einen Warenkorb vorbereitet, übernimmt damit noch nicht die Verantwortung für Zahlung, Auftrag, Stornierung oder Rückerstattung.
Für Geschäftsführungen und Commerce-Verantwortliche ergibt sich daraus eine klare Konsequenz.
Salesforce Commerce Cloud sollte nicht anhand des Umfangs seines Ökosystems beurteilt werden, sondern anhand der konkreten Geschäftsprozesse, die ein Unternehmen damit zuverlässig und wirtschaftlich betreiben kann.
Das gilt für eine Neueinführung ebenso wie für die Weiterentwicklung einer bestehenden Salesforce-Landschaft.
2. Salesforce Commerce Cloud und die Frage der Produktidentität
Eine wechselnde Bezeichnung, unterschiedliche technische Grundlagen
Salesforce hat es seinen Kunden im Jahr 2026 nicht besonders leicht gemacht, die Produktbezeichnungen nachzuvollziehen.
Im Juni stellte das Unternehmen Agentforce Commerce als neue Bezeichnung seiner Commerce-Lösung vor. Damit sollte der strategische Wandel hin zu KI-gestützten Handelsprozessen auch im Produktnamen sichtbar werden.
Wenige Monate später kehrte Salesforce zur bisherigen Bezeichnung zurück. Die aktuelle Produktseite nennt die Lösung Commerce Cloud und verweist ausdrücklich auf Agentforce Commerce als zwischenzeitlichen Namen.
Für diesen Deep Dive verwenden wir deshalb die aktuelle Bezeichnung Salesforce Commerce Cloud.
Agentforce bezeichnet im Folgenden die KI-Agentenplattform und die darauf aufbauenden Funktionen.
Die Namensänderungen sind für sich genommen kein technischer Sachverhalt. Sie verdeutlichen allerdings ein grundsätzliches Problem der Plattformbewertung. Eine gemeinsame Produktbezeichnung sagt wenig darüber aus, wie ein Portfolio intern aufgebaut ist.
Quelle: Salesforce Commerce Cloud, aktuelle Produktübersicht.
Die historische Trennung von B2C und B2B
Salesforce erwarb Demandware 2016 und CloudCraze 2018.
Aus diesen Akquisitionen entstanden zwei Commerce-Produktlinien, die weiterhin unterschiedliche technische Grundlagen besitzen.
B2C Commerce nutzt die Demandware-basierte Commerce-Architektur mit eigenem Laufzeitmodell, Business Manager, Storefront-Technologien und Commerce-APIs.
B2B Commerce nutzt die Salesforce Platform und orientiert sich stärker an deren Datenmodellen, Geschäftskonten, Berechtigungen und Anwendungskomponenten.
Diese Unterschiede betreffen nicht nur die Entwicklung einzelner Funktionen. Sie wirken sich auf Integration, Datenhaltung, Erweiterbarkeit, Betrieb und organisatorische Zuständigkeiten aus.
Ein Unternehmen, das B2C und B2B miteinander verbinden möchte, kann deshalb nicht voraussetzen, dass beide Geschäftsmodelle automatisch auf denselben transaktionalen Datenstrukturen beruhen.
Salesforce beschreibt sein Commerce-Portfolio gleichzeitig als zunehmend integrierte Suite mit gemeinsamen Diensten und einer gemeinsamen Datenbasis.
Dieser Anspruch ist nicht allein wegen der unterschiedlichen historischen Produktarchitekturen zurückzuweisen. Gemeinsame Plattformdienste, Datenzugriffe und integrierte Geschäftsprozesse können auch zwischen technisch unterschiedlichen Anwendungen entstehen.
Entscheidend ist jedoch, wo Daten tatsächlich gemeinsam verwaltet werden, wo sie synchronisiert werden und wo verschiedene Systeme weiterhin eigenständige Geschäftsregeln und Transaktionen ausführen.
Quelle: Salesforce Processor Binding Corporate Rules, Produktverzeichnis.
Das erweiterte Commerce-Portfolio
Neben den beiden Commerce-Produktlinien umfasst das Salesforce-Portfolio weitere Anwendungen.
Salesforce Order Management unterstützt die Bearbeitung und Orchestrierung von Aufträgen. Omnichannel Inventory ergänzt Bestandsprozesse. Salesforce Payments adressiert Zahlungsfunktionen. Die Point-of-Sale-Lösung verbindet stationäre Verkaufsprozesse mit weiteren Salesforce-Anwendungen.
Hinzu kommen Sales Cloud, Service Cloud, Marketing Cloud, Data 360 und Integrationsdienste wie MuleSoft.
Diese Komponenten können gemeinsam eine umfangreiche Handelsarchitektur bilden.
Sie sind jedoch nicht sämtlich Bestandteil eines einzelnen Commerce-Kerns. Ihre technischen Beziehungen und kommerziellen Voraussetzungen müssen jeweils gesondert beurteilt werden.
Die Stärke des Portfolios liegt in seinen Verbindungsmöglichkeiten. Seine Komplexität entsteht aus denselben Verbindungsmöglichkeiten.
3. Die Architektur: Zwei Commerce-Welten innerhalb eines Ökosystems
B2C Commerce und der Demandware-Kern
Salesforce B2C Commerce ist als mandantenfähige SaaS-Lösung konzipiert.
Salesforce betreibt die zugrunde liegende Infrastruktur. Händler konzentrieren sich auf Konfiguration, Entwicklung, Integrationen und den Betrieb ihrer Commerce-Anwendungen.
Der Commerce-Kern stellt unter anderem Funktionen für Produkte, Kategorien, Preisbücher, Promotions, Kundenkonten, Warenkörbe und Bestellungen bereit.
Business Manager dient als zentrale Administrationsumgebung für viele dieser Funktionen.
Dieses Modell hat einen klaren Vorteil. Unternehmen müssen keine eigene Commerce-Infrastruktur aufbauen und deren grundlegenden Plattformbetrieb verantworten.
Die technische Freiheit ist allerdings durch die vorgesehenen Erweiterungsmechanismen, Laufzeitbedingungen und verfügbaren Schnittstellen begrenzt.
Wer umfangreiche individuelle Geschäftslogik entwickelt, muss diese innerhalb des Salesforce-Betriebsmodells realisieren und über dessen Release-Zyklen hinweg pflegen.
Storefront Reference Architecture
Mit der Storefront Reference Architecture, kurz SFRA, stellt Salesforce einen etablierten Ansatz für serverseitig gerenderte B2C-Storefronts bereit.
SFRA verwendet ein JavaScript-basiertes Controller-Modell. Erweiterungen werden unter anderem über Cartridges integriert.
Dieses Modell bietet einen strukturierten Ausgangspunkt für klassische Storefront-Implementierungen.
Seine Flexibilität hängt jedoch davon ab, wie weit ein Unternehmen die Standardarchitektur verändert.
Eine Storefront mit begrenzten Anpassungen lässt sich anders betreiben als eine über Jahre gewachsene Implementierung mit umfangreichen eigenen Cartridges, Controllern und Integrationen.
Die langfristigen Veränderungskosten entstehen deshalb nicht allein aus der Wahl von SFRA, sondern aus der konkreten Erweiterungsarchitektur.
Composable Storefront und Storefront Next
Für entkoppelte Frontends bietet Salesforce Composable Storefront mit PWA Kit und Managed Runtime.
Dabei wird die Storefront auf Basis von React entwickelt und über Commerce-APIs mit den Backend-Funktionen verbunden.
Das eröffnet zusätzliche Möglichkeiten für individuelle Benutzeroberflächen, Frontend-Entwicklung und die Einbindung externer Komponenten.
Die Entkopplung des Frontends bedeutet allerdings nicht, dass auch der Commerce-Kern aus frei austauschbaren Diensten besteht.
Composable Storefront ist zunächst eine alternative Präsentations- und Integrationsarchitektur innerhalb von Salesforce B2C Commerce.
Mit Storefront Next entwickelt Salesforce einen weiteren modernen Storefront-Ansatz.
Dabei muss zwischen der Zielarchitektur und den Werkzeugen für eine Migration unterschieden werden.
Salesforce stellt einen KI-gestützten Migrationsbeschleuniger bereit, der zum Recherchestichtag als Developer Preview dokumentiert ist und nicht für den produktiven Einsatz freigegeben wurde.
Das Werkzeug kann bei der Analyse und teilweisen Übertragung bestehender Storefront-Strukturen unterstützen. Es ersetzt jedoch keine vollständige Migration kundenspezifischer Geschäftslogik.
Individuelle Controller, Zahlungsintegrationen, Lokalisierung, besondere Frontend-Funktionen, Sicherheitstests und Performance-Optimierung bleiben gesonderte Aufgaben.
Für bestehende Händler ergibt sich damit eine Architekturentscheidung, die über das Frontend hinausgeht.
Die Frage ist nicht allein, welche Storefront-Technologie moderner erscheint. Entscheidend ist, welche bestehenden Funktionen, Erweiterungen und Prozessabhängigkeiten mit vertretbarem Aufwand weiterverwendet oder angepasst werden können.
Der Übergang von OCAPI zu SCAPI
Eine besonders konkrete Veränderung betrifft die API-Landschaft.
Salesforce hat die Open Commerce API, OCAPI, im April 2026 offiziell als deprecated eingestuft.
Für neue Implementierungen soll Salesforce Commerce API, SCAPI, verwendet werden. Seit dem 1. September 2026 sind OCAPI-Einstellungen für neu bereitgestellte Kunden-Realms grundsätzlich nicht mehr verfügbar. Bestandskunden können unter bestimmten Voraussetzungen weiterhin Zugriff beantragen.
Salesforce dokumentiert weiterhin Support und sicherheitsrelevante Wartung für OCAPI, hat jedoch kein endgültiges Abschaltdatum festgelegt. Sollte Salesforce die Abschaltung formell beschließen, soll das End-of-Life-Datum mindestens zwei Jahre nach dieser Entscheidung liegen.
Der Übergang betrifft mehr als einzelne API-Endpunkte.
SCAPI verwendet andere Authentifizierungs- und Integrationsmechanismen, insbesondere den Shopper Login and API Access Service, SLAS. Salesforce beschreibt außerdem Unterschiede beim Caching und bei der API-Architektur.
Eine bestehende OCAPI-Integration lässt sich deshalb nicht in jedem Fall durch den Austausch von Endpunktadressen modernisieren.
Unternehmen müssen prüfen, welche Anwendungen OCAPI verwenden, welche individuellen Funktionen betroffen sind, wie Authentifizierung und Sitzungsverwaltung erfolgen und welche Geschäftslogik über vorhandene Hooks oder Erweiterungen implementiert wurde.
SLAS kann dabei unter bestimmten Voraussetzungen eine schrittweise Übergangsarchitektur unterstützen.
Die wirtschaftliche Konsequenz ist weder eine sofortige technische Unbrauchbarkeit bestehender Integrationen noch ein Grund für einen automatischen Plattformwechsel.
Sie ist eine konkrete, planbare Migrationsanforderung.
Quellen: Salesforce OCAPI Deprecation Policy, OCAPI Settings und Why Use SCAPI.
B2B Commerce und die Salesforce Platform
B2B Commerce folgt einer anderen Produktlogik.
Geschäftskonten, Ansprechpartner, Account-Beziehungen und Berechtigungen stehen stärker im Mittelpunkt als beim klassischen anonymen B2C-Einkauf.
Die Architektur nutzt Salesforce-nahe Datenstrukturen und unterstützt die Verbindung mit Vertriebs- und Serviceprozessen.
Dies kann besonders dort relevant sein, wo Kundenbeziehungen bereits innerhalb von Salesforce verwaltet werden.
Allerdings darf aus dieser Nähe nicht geschlossen werden, dass sämtliche Geschäftsregeln von Sales Cloud, Revenue Management und B2B Commerce automatisch übereinstimmen.
Gerade bei Vertragspreisen, Angebotsprozessen, Kreditlimits, Budgets und kundenspezifischen Freigaben muss festgelegt werden, welches System die verbindlichen Regeln enthält und an welcher Stelle sie technisch durchgesetzt werden.
Architektonisch betrachtet ist Salesforce Commerce Cloud damit ein Portfolio mit unterschiedlichen Stärken und Betriebsmodellen. Eine gemeinsame Salesforce-Landschaft kann diese Unterschiede integrieren, aber sie beseitigt sie nicht.
4. Commerce-Funktionalität und die operative Realität
B2C: Umfangreiche Handelsfunktionen mit definierten Erweiterungsgrenzen
Salesforce B2C Commerce deckt wesentliche Anforderungen des digitalen Handels ab.
Dazu gehören Produktkataloge mit Varianten, Preisbücher, Promotions, Content-Funktionen, Suche, Merchandising, Kundenkonten, Warenkörbe und Bestellprozesse.
Multi-Site-Funktionen unterstützen unterschiedliche Marken, Länder und Storefronts. Preise, Sprachen und Sortimente können für verschiedene Märkte verwaltet werden.
Für internationale Handelsorganisationen ist diese Struktur relevant, weil mehrere Vertriebskontexte innerhalb einer Commerce-Landschaft betrieben werden können.
Allerdings ist eine Multi-Site-Funktion nicht mit einem vollständigen internationalen Betriebsmodell gleichzusetzen.
Lokale Steuern, Zahlungsmethoden, rechtliche Anforderungen, Lieferprozesse und organisatorische Verantwortlichkeiten müssen weiterhin abgebildet werden.
Auch die Produktdatenverwaltung verdient eine differenzierte Betrachtung.
B2C Commerce enthält die für den Verkauf benötigten Katalog- und Produktdatenfunktionen. Für komplexe Produktdatenprozesse mit mehreren Lieferanten, umfangreichen Attributmodellen oder kanalübergreifender Datenanreicherung kann dennoch ein externes PIM sinnvoll oder notwendig sein.
Der Commerce-Katalog muss verkaufsfähige Informationen bereitstellen. Er muss nicht zwangsläufig das führende System für sämtliche Produktinformationen eines Unternehmens sein.
Suche, Merchandising und Personalisierung
Salesforce bietet etablierte Funktionen für Suche, Produktplatzierung, Promotions und personalisierte Einkaufserlebnisse.
Einstein-Funktionen und neuere KI-gestützte Suchansätze erweitern diese Möglichkeiten.
Die konkrete Qualität einer Suche hängt jedoch nicht allein von ihrer technischen Ausstattung ab.
Produktdaten, Kategorisierung, Suchverhalten, Synonyme, Verfügbarkeiten und kommerzielle Regeln bestimmen wesentlich mit, ob Kunden relevante Ergebnisse erhalten.
Auch eine KI-gestützte Suche kann unzureichende Produktdaten nicht beliebig kompensieren.
Für das Management entsteht daraus eine wichtige Unterscheidung zwischen verfügbarer Technologie und operativer Leistungsfähigkeit.
Eine neue Suchfunktion kann den technischen Handlungsspielraum erweitern. Ihre wirtschaftliche Wirkung muss unter den realen Bedingungen des jeweiligen Sortiments und Kundenverhaltens nachgewiesen werden.
B2B Commerce: Wenn der Kunde eine Organisation ist
In B2B Commerce verändert sich die grundlegende Struktur des Einkaufs.
Der Kunde ist häufig nicht eine einzelne Person, sondern ein Unternehmen mit mehreren Standorten, Abteilungen und Einkäufern.
Diese Personen können unterschiedliche Rollen, Budgets, Produktberechtigungen und Verantwortlichkeiten besitzen.
Salesforce verwendet für die Zuordnung von Geschäftskunden unter anderem Accounts, Buyer Groups, Entitlement Policies und Price Books.
Über diese Mechanismen lässt sich steuern, welche Käufer bestimmte Produkte sehen und zu welchen Preisen sie einkaufen können.
Buyer Groups ermöglichen beispielsweise kundenspezifische Sortimente und Preisstufen.
Eine Entitlement Policy kann den Zugang zu bestimmten Produkten einschränken. Ein Price Book steuert die zugeordneten Preise.
Damit verfügt B2B Commerce über konkrete Mechanismen zur Abbildung differenzierter Einkaufsbedingungen.
Die Verbindung zwischen Account-Strukturen, Buyer Groups und Preisregeln muss allerdings bewusst gestaltet werden. Komplexe Organisationshierarchien entstehen nicht automatisch durch die Verwendung eines gemeinsamen CRM-Datenmodells.
Quelle: Salesforce: Buyer Groups, Entitlements and Pricing Strategies.
Vertragspreise und Angebotsprozesse
Bei anspruchsvollen B2B-Geschäftsmodellen wird die Preislogik häufig zum zentralen Architekturthema.
Ein Hersteller kann mit einem Kunden individuelle Konditionen vereinbaren, die von Mengen, Produktgruppen, Vertragslaufzeiten oder Rahmenvereinbarungen abhängen.
B2B Commerce kann kundenspezifische Preise und Produktberechtigungen abbilden.
Bei komplexeren Angebots- und Verhandlungsprozessen kommen jedoch weitere Salesforce-Anwendungen und Geschäftsregeln hinzu.
Salesforce dokumentiert beispielsweise einen Request-for-Quote-Prozess, bei dem Käufer aus ihrem Warenkorb eine Angebotsanfrage erstellen können.
Der Vertrieb kann Preise, Mengen und Konditionen bearbeiten. Kunden können das Angebot anschließend annehmen oder erneut verhandeln.
Die Bearbeitung erfolgt je nach Konfiguration über Sales Cloud beziehungsweise Agentforce Revenue Management.
Ein genehmigtes Angebot kann anschließend in den Einkaufsprozess übernommen werden.
Damit wird deutlich, dass die Commerce-Storefront nicht zwingend das führende System für sämtliche Preis- und Vertragsentscheidungen ist.
Quelle: Salesforce: Request for Quote.
Einkaufsfreigaben, Budgets und Beschaffungsregeln
Ein weiterer Unterschied zum B2C-Commerce betrifft die Autorisierung von Bestellungen.
Ein Mitarbeiter kann beispielsweise Waren auswählen dürfen, ohne sie selbst verbindlich bestellen zu können.
Eine Einkaufsabteilung kann Budgetgrenzen festlegen. Bestellungen oberhalb bestimmter Beträge benötigen möglicherweise eine zusätzliche Genehmigung.
Nicht jede dieser Regeln ist in jeder B2B-Commerce-Edition als vollständig integrierter Standardprozess verfügbar.
Auch die Verbindung zu Salesforce Flow, Revenue Management oder externen Beschaffungssystemen kann erforderlich sein.
Für die Architekturentscheidung muss deshalb zwischen drei Ebenen unterschieden werden.
Die Storefront kontrolliert, welche Produkte ein Käufer sehen und auswählen darf.
Die Beschaffungsorganisation bestimmt, welche Person eine Bestellung genehmigen oder auslösen darf.
Das ERP beziehungsweise das führende Auftragssystem entscheidet gegebenenfalls über Kreditlimits, Verfügbarkeit, Vertragsbedingungen und die verbindliche Annahme eines Auftrags.
Diese Regeln können sich überschneiden. Sie dürfen jedoch nicht widersprüchlich sein.
Ein typischer B2B-Beschaffungsprozess
Ein Geschäftskunde meldet sich in seinem Einkaufsportal an.
Die Commerce-Anwendung identifiziert das zugehörige Geschäftskonto und ermittelt die zugelassenen Produkte sowie die gültigen Preisbücher.
Der Käufer stellt eine Bestellung zusammen.
Für einen Teil der Artikel gelten bereits verhandelte Preise. Für andere Produkte wird zunächst ein Angebot angefordert.
Der zuständige Vertrieb bearbeitet die Anfrage. Die genehmigten Konditionen werden anschließend für den Einkauf bereitgestellt.
Vor der verbindlichen Bestellung muss geprüft werden, ob der Käufer über die notwendigen Berechtigungen verfügt und ob gegebenenfalls interne Freigaben erforderlich sind.
Danach können ERP, Warenwirtschaft und Order Management für weitere Prüfungen und die Auftragsbearbeitung zuständig sein.
Die technische Qualität einer solchen Lösung entscheidet sich daran, wie zuverlässig diese Schritte miteinander verbunden sind.
Eine funktionierende Produktansicht und ein erfolgreicher Checkout genügen nicht als Nachweis für eine vollständige B2B-Beschaffungsarchitektur.
Wiederkehrende Beschaffung
Für Geschäftskunden sind Wiederbestellungen, Einkaufslisten und Schnellbestellungen wichtige Funktionen.
Salesforce unterstützt entsprechende B2B-Szenarien.
Ein wiederkehrender Einkauf ist allerdings nicht automatisch mit einer rechtlich oder technisch autorisierten Dauerbestellung gleichzusetzen.
Bei automatisierten Beschaffungsprozessen müssen Preisänderungen, Verfügbarkeiten, Lieferbedingungen und Freigabegrenzen weiterhin berücksichtigt werden.
Mit Agentforce gewinnt diese Unterscheidung zusätzliche Bedeutung, weil KI-Agenten künftig auch Wiederbestellungen vorbereiten oder auslösen können.
Im B2B-Commerce entscheidet die zuverlässige Durchsetzung von Vertrags- und Beschaffungsregeln häufig stärker über den Projekterfolg als der Umfang der sichtbaren Storefront-Funktionen.
5. Unified Commerce: Wenn die Integration zur eigentlichen Plattform wird
Salesforce beschreibt Commerce Cloud als Bestandteil einer einheitlichen Handelsarchitektur.
Mit eigenen Lösungen für Commerce, Point of Sale, Order Management, Payments und Datenintegration besitzt das Unternehmen wesentliche Bausteine für diesen Anspruch.
Das Portfolio ist damit umfangreicher, als es die traditionelle Betrachtung von Salesforce Commerce Cloud als reiner Online-Shop vermuten lässt.
Die entscheidende Frage betrifft jedoch die operative Verbindung dieser Bausteine.
Kundenidentität und gemeinsame Kundensicht
Sales Cloud, Service Cloud und Data 360 können Informationen aus unterschiedlichen Kundeninteraktionen zusammenführen.
Die Möglichkeit, Kundeninformationen kanalübergreifend zugänglich zu machen, ist eine relevante Stärke des Salesforce-Ökosystems.
Data 360 kann dabei helfen, Daten aus verschiedenen Quellen zu vereinheitlichen und für Analysen oder Anwendungen bereitzustellen.
Eine zusammengeführte Kundensicht ist allerdings nicht automatisch eine gemeinsame transaktionale Kundenidentität.
Ein registrierter B2C-Kunde, ein B2B-Geschäftskonto, ein stationärer Käufer und ein Servicekontakt können unterschiedlichen Identitäts- und Berechtigungsmodellen unterliegen.
Damit aus diesen Informationen ein operativ nutzbarer Zusammenhang entsteht, müssen Identitätsauflösung, Datenqualität, Berechtigungen und Verantwortlichkeiten definiert werden.
Das ist nicht allein eine technische Integrationsaufgabe.
Es ist ebenso eine Frage der Daten-Governance.
Bestand und Auftragsorchestrierung
Omnichannel Inventory und Salesforce Order Management ergänzen Commerce um Funktionen für die Bestandsverfügbarkeit und kanalübergreifende Auftragsbearbeitung.
Solche Funktionen sind Voraussetzungen für Prozesse wie Click & Collect, Ship-from-Store oder die Zuordnung von Bestellungen zu unterschiedlichen Fulfilment-Standorten.
Ihre Verfügbarkeit innerhalb des Salesforce-Portfolios bedeutet jedoch nicht, dass jeder Händler automatisch einen einheitlichen Bestand besitzt.
Bestandsführende ERP- oder Warenwirtschaftssysteme bleiben häufig beteiligt.
Ebenso müssen Reservierungen, Stornierungen, Teillieferungen und Bestandsänderungen konsistent verarbeitet werden.
Wenn ein Produkt online verfügbar erscheint, im Geschäft aber bereits verkauft wurde, ist das zunächst ein Problem der tatsächlichen Prozess- und Datenkonsistenz.
Die Bezeichnung der eingesetzten Commerce-Suite löst dieses Problem nicht.
Salesforce Point of Sale
Durch die Übernahme von PredictSpring hat Salesforce seine Möglichkeiten für stationären Handel erweitert.
Die aktuelle Point-of-Sale-Lösung adressiert unter anderem Filialverkauf, Kundeninteraktion, Bestandsinformationen und Omnichannel-Funktionen.
Damit ist die ältere Aussage, Salesforce müsse POS grundsätzlich über Drittanbieter abbilden, nicht mehr zutreffend.
Gleichzeitig muss eine POS-Integration nach ihren konkreten Prozessfähigkeiten beurteilt werden.
Können online gekaufte Artikel in der Filiale retourniert werden? Sind Promotions kanalübergreifend konsistent? Welche Systeme bearbeiten Erstattungen? Werden Kundenidentitäten zuverlässig zugeordnet? Wie werden stationäre Bestandsbewegungen übertragen?
Erst die Antworten auf solche Fragen zeigen, ob aus mehreren Vertriebskanälen ein tatsächlich integrierter Handelsprozess entsteht.
Ein kanalübergreifender Kaufprozess als Architekturprüfung
Betrachten wir einen Händler mit eigenem Online-Shop und mehreren Filialen.
Eine Kundin bestellt einen Artikel online. Die Bestellung soll aus einer nahegelegenen Filiale versendet werden.
Einige Tage nach der Lieferung entscheidet sich die Kundin, den Artikel in einer anderen Filiale zurückzugeben.
Dieser Vorgang erscheint aus Kundensicht einfach.
Technisch umfasst er mehrere unterschiedliche Verantwortlichkeiten.
Zunächst muss die Online-Storefront die korrekte Produktvariante und den gültigen Verkaufspreis ermitteln.
Anschließend wird die verfügbare Menge geprüft.
Dabei reicht es nicht aus, dass die betreffende Filiale einen positiven Bestand meldet. Die Ware muss für den vorgesehenen Fulfilment-Prozess verfügbar und gegebenenfalls reservierbar sein.
Nach der Bestellung muss ein Auftragsmanagementsystem entscheiden, welcher Standort die Lieferung übernimmt.
Das Filialsystem beziehungsweise die dort eingesetzten operativen Anwendungen müssen den Auftrag erhalten und die tatsächliche Kommissionierung abbilden.
Wenn der Artikel verkauft oder versendet wird, müssen die Bestandsbewegungen in den relevanten Systemen konsistent verarbeitet werden.
Bei der späteren Retoure beginnt ein weiterer Prozess.
Die zweite Filiale muss die ursprüngliche Bestellung identifizieren und prüfen, ob eine Rückgabe zulässig ist.
Anschließend müssen Warenbewegung, Auftragsstatus und Erstattung korrekt verarbeitet werden.
Je nach Zahlungsart und Vertragsstruktur sind unterschiedliche Zahlungs- und Finanzsysteme beteiligt.
Salesforce bietet für viele dieser Aufgaben eigene Produkte und Integrationsmöglichkeiten.
Die Verbindung zwischen Commerce, POS, Omnichannel Inventory, Order Management, ERP und Payments muss jedoch entsprechend konfiguriert oder implementiert werden.
Der beschriebene Ablauf ist ein analytisches Prozessbeispiel und kein Nachweis dafür, dass jede Salesforce-Commerce-Installation ihn ohne zusätzliche Konfiguration unterstützt.
Er verdeutlicht vielmehr die Anforderungen, die eine tatsächlich durchgängige Handelsarchitektur erfüllen muss.
Unified Commerce entsteht nicht bereits dadurch, dass alle beteiligten Anwendungen vom selben Anbieter stammen. Er entsteht, wenn Daten, Geschäftsregeln und operative Verantwortlichkeiten über die gesamte Transaktion hinweg konsistent bleiben.
Europäische Praxis und regionale Voraussetzungen
Für Unternehmen in Deutschland und der Europäischen Union kommt eine weitere Dimension hinzu.
Nicht alle Salesforce-Commerce-Produkte, Zahlungsfunktionen und Agentforce-Integrationen stehen in jeder Region mit identischem Leistungsumfang zur Verfügung.
Bei internationalen Handelsarchitekturen müssen unter anderem die unterstützten Länder, Zahlungsdienstleister, Währungen, Datenverarbeitungsbedingungen und steuerlichen Anforderungen geprüft werden.
Auch die Nutzung von Salesforce Point of Sale ist anhand des konkret angebotenen Produkts und seiner regionalen Vertrags- und Integrationsvoraussetzungen zu beurteilen.
Die öffentliche Salesforce-Preisübersicht beschreibt Retail Cloud Point-of-Sale als eigenständiges Angebot. Daraus folgt jedoch keine gesicherte Aussage, dass jede gewünschte Länder- und Funktionskombination produktiv unterstützt wird.
Für Salesforce Payments gelten ebenfalls produktspezifische Voraussetzungen. Internationale Storefronts allein belegen nicht die Unterstützung sämtlicher lokaler Zahlungsverfahren.
Datenschutzrechtlich sind insbesondere die Rollen der beteiligten Unternehmen, Datenflüsse, Auftragsverarbeitungsverträge und gegebenenfalls internationale Übermittlungen zu prüfen.
Eine pauschale Behauptung vollständiger DSGVO-Konformität allein aufgrund der Nutzung einer Salesforce-Cloud wäre unzureichend.
Quelle: Salesforce Commerce Pricing & Editions.
Die wirtschaftliche Dimension von Unified Commerce
Unified Commerce kann Kundenerlebnisse verbessern und operative Reibungsverluste verringern.
Dafür müssen jedoch gegebenenfalls zusätzliche Anwendungen lizenziert, Systeme integriert und Geschäftsprozesse vereinheitlicht werden.
Nicht jede Handelsorganisation benötigt sämtliche Komponenten.
Ein Händler mit wenigen Filialen, einem klaren Online-Geschäft und einem leistungsfähigen bestehenden ERP kann andere Anforderungen haben als ein internationaler Konzern mit zahlreichen Marken, Lagern und Vertriebsgesellschaften.
Die strategische Frage lautet deshalb nicht, ob ein vollständiger Salesforce-Stack aufgebaut werden kann.
Sie lautet, welcher Grad an Integration einen nachweisbaren wirtschaftlichen Nutzen erzeugt und welche Systeme dafür tatsächlich erforderlich sind.
6. Agentic Commerce: Von der Produktberatung zur Transaktion
Mit Agentforce hat Salesforce seine Commerce-Strategie deutlich erweitert.
KI-Agenten sollen nicht nur Informationen bereitstellen, sondern Aufgaben innerhalb von Handelsprozessen übernehmen.
Das betrifft sowohl interne Tätigkeiten von Händlern als auch die Interaktion mit Endkunden und Geschäftskäufern.
Der Produktstand im Oktober 2026 zeigt erhebliche Fortschritte. Gleichzeitig bleibt die Unterscheidung zwischen angekündigten Möglichkeiten, allgemein verfügbaren Funktionen und tatsächlich durchgängigen Prozessen entscheidend.
Shopper Agent, Buyer Agent und Merchant Agent
Salesforce erklärte im Sommer 2026 drei Commerce-Agenten für allgemein verfügbar.
Der Shopper Agent richtet sich an B2C-Kunden und unterstützt konversationelle Einkaufserlebnisse. Produkte können gefunden, erklärt und im Kontext eines Einkaufsprozesses angeboten werden.
Der Buyer Agent adressiert Geschäftskunden und unterstützt B2B-Beschaffungsszenarien, unter anderem über Messaging-Kanäle.
Der Merchant Agent ist auf Aufgaben innerhalb der Handelsorganisation ausgerichtet, etwa Katalogpflege, Merchandising-Aktivitäten oder die Bearbeitung bestimmter operativer Informationen.
Diese Funktionen unterscheiden sich hinsichtlich ihrer Aufgaben und der erforderlichen Berechtigungen.
Ein Merchant Agent, der Produktdaten verändert, benötigt andere Zugriffsrechte als ein Shopping Agent, der Kunden bei einer Bestellung unterstützt.
Ein B2B-Agent, der eine Wiederbestellung vorbereitet, muss wiederum die geltenden Geschäfts- und Beschaffungsregeln berücksichtigen.
Auch der GA-Status eines übergeordneten Produkts bedeutet nicht, dass jede mögliche Funktion in jeder Edition, Region und technischen Konfiguration verfügbar ist.
Bei B2B Guided Shopping dokumentiert Salesforce zusätzliche Voraussetzungen, darunter entsprechende Commerce- und Agentforce-Lizenzen sowie die Einrichtung benötigter Daten- und KI-Dienste.
Die tatsächliche Bereitstellung eines Agenten ist deshalb immer anhand des konkreten Anwendungsfalls zu prüfen.
Quelle: Salesforce: Agentforce Commerce Release, Juli 2026.
Externe KI-Agenten und die Bedeutung offener Protokolle
Neben Salesforce-eigenen Agenten entwickelt sich ein zweiter Zugangsweg zum Handel.
Externe KI-Assistenten können Produktinformationen abrufen, Einkaufsprozesse unterstützen und unter bestimmten Voraussetzungen Transaktionen auslösen.
Für Händler verändert sich dadurch die Rolle der eigenen Storefront.
Sie bleibt für viele Vorgänge relevant, ist aber nicht mehr zwangsläufig der einzige Ort, an dem eine Kaufentscheidung vorbereitet oder abgeschlossen wird.
Damit gewinnen technische Standards und interoperable Schnittstellen an Bedeutung.
Salesforce verfolgt mehrere Ansätze, deren Fähigkeiten und Reifegrad unterschiedlich sind.
MCP: Werkzeugzugang ist noch kein autonomer Kauf
Salesforce dokumentiert für B2C Commerce einen MCP Shopper Service, der externen KI-Assistenten Zugriff auf ausgewählte Commerce-Funktionen ermöglicht.
Zu den beschriebenen Fähigkeiten gehören Produktsuche, Produktinformationen und die Vorbereitung eines Warenkorbs.
Der dokumentierte Einkaufsprozess führt anschließend über einen Link zum Checkout des Händlers.
Der MCP Shopper Service befindet sich im Oktober 2026 im Pilotbetrieb.
Salesforce beschreibt ihn außerdem ausdrücklich als eigenständiges Angebot, das nicht mit dem Agentforce Shopper Agent gleichgesetzt werden darf.
Die verfügbare Werkzeugauswahl ist begrenzt. Sie stellt keine uneingeschränkte Freigabe sämtlicher SCAPI-Funktionen dar.
Auch die Authentifizierung erfolgt über definierte technische Berechtigungen, unter anderem über SLAS.
Ein externer Agent kann damit Commerce-Werkzeuge nutzen, ohne dass er bereits eine vollständige Transaktion einschließlich Zahlungsautorisierung und nachgelagerter Auftragsbearbeitung ausführt.
MCP adressiert zunächst die strukturierte Bereitstellung und Nutzung von Werkzeugen und Informationen.
Die geschäftliche Autorisierung einer Zahlung oder die Delegation einer Kaufentscheidung werden dadurch nicht automatisch gelöst.
UCP: Dokumentierte transaktionale Integration mit Einschränkungen
Beim Universal Commerce Protocol ist Salesforce technisch bereits weiter.
Die Salesforce-UCP-Implementierung ist ab B2C Commerce Release 26.9 allgemein verfügbar.
Sie ermöglicht die Bereitstellung eines maschinenlesbaren Geschäftsprofils sowie protokollbasierte Checkout-Sessions.
Externe Plattformen können auf dieser Grundlage Commerce-Funktionen nutzen, während der Händler weiterhin Merchant of Record bleibt.
Die technische Dokumentation beschreibt außerdem Zahlungsintegration und die Übermittlung nachgelagerter Bestellereignisse.
Damit geht die Implementierung deutlich über reine Produktdatenfeeds hinaus.
Allerdings gelten im Oktober 2026 wesentliche Einschränkungen.
Salesforce dokumentiert die UCP-Unterstützung aktuell für en-US-Sites. Google wird als erster produktiver Plattformpartner genannt. Händler müssen ein gesondertes Onboarding durchlaufen.
Zu den Voraussetzungen gehören unter anderem entsprechende Business-Manager-Einstellungen, ein geeigneter Zahlungsanbieter, technische Authentifizierung über SLAS und ein für den externen Kanal geeigneter Produktfeed.
Für Google sind zusätzlich Merchant-Center-Konfiguration, Freischaltung und End-to-End-Tests erforderlich.
Eine allgemein verfügbare Salesforce-Implementierung bedeutet deshalb nicht, dass jeder europäische Händler sofort in jeder Sprache und auf jedem KI-Kanal verkaufen kann.
Quellen: Salesforce UCP Integration Guide und Enabling Google as a Platform.
Checkout-Sessions und bestehende Geschäftslogik
Die technische Dokumentation zeigt eine besonders relevante Integrationsanforderung.
UCP-Checkout-Sessions verwenden den vorhandenen B2C-Commerce-Warenkorb und die zugrunde liegenden Auftragsfunktionen.
Dabei werden bestimmte Standard-Hooks weiterhin ausgeführt.
Dazu gehören unter anderem Funktionen zur Berechnung von Preisen, Steuern und Versandkosten sowie zur Validierung des Warenkorbs.
Allerdings werden individuelle Storefront-Controller und bestimmte ressourcenspezifische API-Erweiterungen nicht automatisch ausgeführt.
Geschäftsregeln, die bisher ausschließlich in diesen Komponenten implementiert waren, müssen deshalb überprüft und gegebenenfalls auf geeignete UCP- beziehungsweise Commerce-Hooks übertragen werden.
Das bedeutet nicht, dass UCP die gesamte bestehende Commerce-Geschäftslogik grundsätzlich umgeht.
Es bedeutet, dass eine produktive Integration den vollständigen tatsächlichen Checkout eines Händlers berücksichtigen muss.
Dazu können Mindestbestellwerte, Lieferbeschränkungen, individuelle Preisprüfungen, Adressvalidierungen, Compliance-Anforderungen oder besondere Zahlungsregeln gehören.
Auch die nachgelagerte Auftragsbearbeitung erfordert eine präzise Betrachtung.
Salesforce dokumentiert signierte Ereignisse zur Übermittlung von Änderungen am Bestellstatus. Daraus folgt jedoch kein uneingeschränkter Zugriff auf sämtliche Auftragsfunktionen über UCP.
In Release 26.9 ist beispielsweise kein allgemeiner Shopper-Order-GET über UCP dokumentiert.
Die technische Integration besitzt damit bereits transaktionale Fähigkeiten, ist aber nicht mit einer universellen Auftragsmanagement-Schnittstelle gleichzusetzen.
Quellen: UCP Configuration and Discovery und UCP Implementation Considerations.
ACP und weitere Protokollansätze
Salesforce hat auch die Zusammenarbeit mit OpenAI und Stripe im Umfeld des Agentic Commerce Protocol angekündigt.
Diese Zusammenarbeit ist für die strategische Ausrichtung relevant.
Sie sollte jedoch nicht mit der technisch dokumentierten UCP-Implementierung gleichgesetzt werden.
Für ACP sind Integrationsansätze und Produktdatenanbindungen beschrieben. Eine gleichermaßen vollständige und allgemein verfügbare Salesforce-Commerce-Implementierung aller transaktionalen Funktionen ließ sich zum Recherchestichtag nicht hinreichend nachweisen.
Für AP2 und WebMCP liegt ebenfalls kein ausreichender Nachweis vor, um eine konkrete, allgemein verfügbare Commerce-Implementierung von Salesforce zu behaupten.
Das bedeutet nicht, dass entsprechende Integrationen technisch unmöglich sind.
Es bedeutet lediglich, dass sie nicht als belegte Standardfähigkeit in eine Investitionsentscheidung übernommen werden sollten.
Agentic Commerce in Europa
Die regionalen Einschränkungen verdienen eine besondere Betrachtung.
Ein europäischer Händler kann grundsätzlich KI-gestützte Produktsuche, Beratung und Warenkorbvorbereitung ermöglichen, ohne dass sämtliche Funktionen eines externen Transaktionsprotokolls bereits regional verfügbar sind.
Solche Szenarien müssen deshalb unterschieden werden.
Ein Produktfeed für einen externen KI-Kanal bedeutet zunächst, dass Produkte dort auffindbar werden können.
Eine konversationelle Produktempfehlung kann den Kunden beraten.
Eine Warenkorbvorbereitung kann den Einkauf vereinfachen.
Erst ein tatsächlich unterstützter Checkout einschließlich gültiger Preise, Steuern, Lieferbedingungen und Zahlungsautorisierung ermöglicht einen vollständigen transaktionalen Prozess.
Die im Oktober 2026 dokumentierte en-US-Beschränkung der Salesforce-UCP-Integration darf daher weder ignoriert noch auf den gesamten europäischen Agentic-Commerce-Markt übertragen werden.
Europäische Händler wie OTTO, Carrefour, Knuspr oder dm können eigene KI-gestützte Einkaufserlebnisse entwickeln. Aus solchen Initiativen lässt sich jedoch keine Salesforce-spezifische Produktfähigkeit ableiten, solange die tatsächlich eingesetzte Architektur nicht nachgewiesen ist.
Für die Beurteilung von Salesforce Commerce Cloud sind daher die eigenen technischen und regionalen Produktfreigaben maßgeblich.
Von der Empfehlung zum Kaufabschluss
Für die Bewertung von Agentic Commerce ist es hilfreich, einen vollständigen Kaufprozess zu betrachten.
Die Produktfindung ist nur der Anfang.
Anschließend müssen Varianten, Preise, Verfügbarkeit und Lieferbedingungen geklärt werden. Der Käufer oder sein bevollmächtigter Agent muss die Transaktion bestätigen beziehungsweise ausführen dürfen. Die Zahlung muss autorisiert und die Bestellung zuverlässig erstellt werden.
Nach dem Kauf entstehen weitere Anforderungen.
Bestellungen können verändert oder storniert werden. Lieferungen verzögern sich. Artikel werden retourniert. Erstattungen müssen verarbeitet werden.
Eine konversationelle Oberfläche allein deckt diese Anforderungen nicht ab.
Die eigentliche Reife einer Agentic-Commerce-Architektur zeigt sich nicht daran, ob ein Agent Produkte empfehlen kann, sondern daran, wie zuverlässig und kontrollierbar er in verbindliche Geschäftsprozesse eingebunden ist.
Salesforce verfügt hierfür über mehrere relevante Bausteine.
Welche davon in einem konkreten Szenario tatsächlich zusammenarbeiten, bleibt eine Architektur- und Implementierungsfrage.
7. Identität, Berechtigungen und Kontrolle
Mit agentengestützten Kaufprozessen verändert sich die Frage nach Verantwortlichkeit.
In einem klassischen Checkout bestätigt der Käufer seine Bestellung innerhalb einer vom Händler kontrollierten Oberfläche.
Bei einem externen KI-Agenten können Produktauswahl, Warenkorbvorbereitung und Teile der Transaktion außerhalb dieser Oberfläche stattfinden.
Damit müssen mehrere Identitäten und Berechtigungsebenen unterschieden werden.
Käuferidentität und technische Authentifizierung
Die Identität des menschlichen Käufers ist nicht automatisch identisch mit der technischen Identität des Agenten.
Ein Agent kann mit eigenen technischen Zugangsdaten arbeiten, im Auftrag eines Kunden handeln oder lediglich Informationen für einen später vom Kunden bestätigten Vorgang vorbereiten.
Salesforce bietet mit SLAS und weiteren Authentifizierungsmechanismen technische Grundlagen für die gesicherte Nutzung von Commerce-Funktionen.
Für die UCP-Integration dokumentiert Salesforce beispielsweise einen eigenen technischen Scope für die Verwaltung von Checkout-Sessions.
Damit lässt sich kontrollieren, welche Anwendung entsprechende API-Funktionen aufrufen darf.
Eine gültige technische Authentifizierung belegt jedoch nicht automatisch, dass der Agent zur Durchführung jeder damit technisch möglichen Geschäftshandlung berechtigt ist.
Das Mandat eines Einkaufsagenten
Ein autonom handelnder Agent benötigt klare Grenzen.
Diese können sich beispielsweise auf Produkte, Mengen, Gesamtpreise, Lieferbedingungen, Bezugsquellen oder wiederkehrende Verpflichtungen beziehen.
Dabei reicht es nicht aus, solche Regeln ausschließlich in einer natürlichsprachlichen Anweisung an den Agenten festzuhalten.
Entscheidend ist, an welcher technischen Stelle die Regeln überprüft und verbindlich durchgesetzt werden.
Ein Budgetlimit, das nur in einer Agentenanweisung steht, bietet eine andere Verlässlichkeit als eine serverseitige Prüfung unmittelbar vor Auftragsannahme oder Zahlungsautorisierung.
Dasselbe gilt für Einkaufsfreigaben, Ersatzartikel und die Änderung bereits ausgelöster Bestellungen.
Die Delegation muss außerdem widerrufbar sein, sofern der konkrete Geschäftsprozess dies verlangt.
Commerce-seitige Regeldurchsetzung
Die Commerce-Plattform ist für wesentliche Teile der transaktionalen Geschäftslogik verantwortlich.
Dazu gehören beispielsweise Preisberechnung, Verfügbarkeit, Lieferbedingungen und bestimmte Warenkorbvalidierungen.
Bei einem agentengestützten Checkout müssen diese Regeln unabhängig davon gelten, ob der Kunde über die eigene Storefront oder einen externen Kanal einkauft.
Die Dokumentation der Salesforce-UCP-Integration zeigt, dass bestehende Commerce-Hooks hierfür genutzt werden können.
Sie zeigt gleichzeitig, dass individuell implementierte Regeln nicht automatisch an jedem neuen Integrationspunkt ausgeführt werden.
Damit wird die technische Platzierung von Geschäftsregeln zu einer Governance-Frage.
Eine geschäftskritische Prüfung sollte nicht ausschließlich von einer bestimmten Benutzeroberfläche abhängen.
Zahlungsautorisierung und Delegation
Die Erlaubnis, Produktinformationen abzurufen oder einen Warenkorb anzulegen, ist nicht mit einer Zahlungsautorisierung gleichzusetzen.
Auch eine gültige technische Sitzung beweist nicht automatisch, dass ein Agent einen beliebigen Betrag ausgeben darf.
Die Verantwortlichkeiten von Agentenplattform, Commerce-System, Zahlungsdienstleister und Händler müssen deshalb voneinander abgegrenzt werden.
Für vollständige autonome Kaufmandate einschließlich Budgetdurchsetzung, Widerruf und wiederkehrender Verpflichtungen konnte zum Recherchestichtag keine universell verfügbare Salesforce-Commerce-Standardlösung nachgewiesen werden.
Diese Anforderungen können je nach Architektur zusätzliche Komponenten oder individuelle Regeln erfordern.
Protokollierung und nachgelagerte Kontrolle
Ein agentengestützter Prozess muss nachvollziehbar bleiben.
Für den Kundenservice sollte erkennbar sein, welche Bestellung vorliegt, welche Produkte ausgewählt wurden, welche Bestätigung erfolgte und welche Änderungen anschließend vorgenommen wurden.
Für die interne Governance sind zusätzlich Berechtigungen, technische Aktionen und mögliche Eskalationen relevant.
Dabei müssen Datenschutz und Datenminimierung berücksichtigt werden.
Nicht jeder Agent benötigt Zugriff auf vollständige Kundenprofile oder historische Transaktionsdaten.
Die zentrale Aufgabe besteht darin, jedem Prozess nur die tatsächlich notwendigen Informationen und Handlungsrechte zur Verfügung zu stellen.
Damit entsteht ein mehrstufiges Kontrollmodell.
Die technische Authentifizierung bestimmt, welches System zugreifen darf.
Das geschäftliche Mandat bestimmt, welche Entscheidung ein Agent treffen darf.
Die Commerce-Anwendung muss verbindliche Geschäftsregeln durchsetzen.
Der Zahlungsprozess muss die finanzielle Autorisierung sicherstellen.
Anschließend müssen die Transaktion und mögliche Folgehandlungen nachvollziehbar bleiben.
Diese Kontrollebenen können durch verschiedene Anwendungen realisiert werden.
Sie dürfen jedoch nicht miteinander verwechselt werden.
Agentic Commerce erweitert damit nicht nur die technische Architektur. Er erweitert die Verantwortung für die Gestaltung und Kontrolle von Geschäftsentscheidungen.
8. Betrieb, Erweiterbarkeit und technische Veränderungskosten
SaaS reduziert Infrastrukturaufwand, nicht Integrationsverantwortung
Salesforce Commerce Cloud wird als SaaS betrieben.
Die Verantwortung für grundlegende Plattforminfrastruktur, bestimmte Sicherheitsmaßnahmen und zentrale Softwarebereitstellung liegt damit beim Hersteller.
Das reduziert den Bedarf an eigener technischer Infrastruktur.
Die Verantwortung für die konkrete Geschäftsarchitektur bleibt jedoch beim Unternehmen und seinen Dienstleistern.
Integrationen zu ERP, PIM, Payment, Kundenservice und weiteren Anwendungen müssen gestaltet und betrieben werden.
Dasselbe gilt für individuelle Erweiterungen, Datenflüsse und Geschäftsregeln.
In einer umfangreichen Salesforce-Landschaft kann dadurch ein erheblicher Koordinationsbedarf entstehen.
Release-Management und technische Abhängigkeiten
B2C Commerce und Salesforce-Platform-basierte Anwendungen folgen nicht in sämtlichen Bereichen demselben technischen Release-Verfahren.
Für B2C Commerce dokumentiert Salesforce produktspezifische Versionen, API-Änderungen und Storefront-Entwicklungen.
Auf der Salesforce Platform existieren wiederum eigene Release- und Deployment-Mechanismen.
Unternehmen, die mehrere dieser Produkte kombinieren, müssen deshalb die jeweiligen Änderungszyklen berücksichtigen.
Besonders relevant wird dies bei eigenen Erweiterungen.
Eine Anpassung innerhalb eines Commerce-Cartridges, eine Änderung an einer API-Integration und eine Erweiterung des Salesforce-Datenmodells können unterschiedliche Test- und Deployment-Prozesse erfordern.
Die Modernisierung bestehender Implementierungen
Für ältere B2C-Commerce-Landschaften entstehen zunehmend konkrete Modernisierungsfragen.
Dazu gehört der Übergang von OCAPI zu SCAPI.
Auch die Wahl zwischen SFRA, Composable Storefront und Storefront Next kann relevant werden.
Allerdings sollte eine technische Modernisierung nicht als Selbstzweck betrachtet werden.
Eine neue Frontend-Technologie schafft nicht automatisch bessere Geschäftsprozesse.
Ein Wechsel der Storefront-Architektur kann sinnvoll sein, wenn bestehende technische Grenzen die Entwicklung wesentlich behindern oder eine neue Architektur klare betriebliche Vorteile bietet.
Er kann wirtschaftlich fragwürdig werden, wenn umfangreiche individuelle Funktionen ohne ausreichenden Nutzen neu entwickelt werden müssen.
Integrationen und MuleSoft
MuleSoft ist ein wichtiger Bestandteil des Salesforce-Integrationsportfolios.
Die Plattform kann bei komplexen Integrationsanforderungen eine geeignete Rolle übernehmen.
Ihre Verwendung ist jedoch nicht automatisch Voraussetzung für jede Salesforce-Commerce-Implementierung.
Bestehende Middleware, direkte APIs, Integrationsplattformen und spezialisierte Konnektoren können je nach Architektur ebenfalls sinnvoll sein.
Die Auswahl sollte sich nach Anforderungen an Datenkonsistenz, Prozesssteuerung, Sicherheit, Fehlertoleranz und Betrieb richten.
Partnerabhängigkeiten
Salesforce verfügt über ein umfangreiches Partner- und Implementierungsökosystem.
Dennoch sind Kenntnisse aus allgemeinen Salesforce-Projekten nicht ohne Weiteres mit tiefgehender B2C-Commerce-Erfahrung gleichzusetzen.
SFRA, Cartridges, SCAPI, Storefront Next und Commerce-spezifische Betriebsmodelle verlangen entsprechendes Fachwissen.
Das gilt ebenso für komplexe B2B-Commerce-Projekte und produktübergreifende Integrationen.
Der Bedarf an spezialisierten Kompetenzen sollte frühzeitig in der Projektplanung berücksichtigt werden.
Die wichtige wirtschaftliche Größe ist dabei nicht nur die Verfügbarkeit von Implementierungspartnern.
Entscheidend ist, wie viel technisches und fachliches Wissen das Unternehmen selbst dauerhaft benötigt, um seine Commerce-Landschaft verändern und kontrollieren zu können.
9. Wirtschaftlichkeit: Die Kosten der Gesamtarchitektur
Eine Lizenz ist noch kein Geschäftsmodell
Salesforce Commerce Cloud umfasst unterschiedliche Produkte, Editionen und vertragliche Modelle.
Öffentliche Preisübersichten zeigen beispielsweise eigenständige Angebote für B2C Commerce, B2B Commerce, Order Management, POS und Payments.
Der konkrete Leistungsumfang unterscheidet sich je nach Edition.
Die aktuelle öffentliche Preisübersicht nennt für Commerce Cloud B2C Premium umfangreiche Order-Management-Funktionen.
Für B2B Growth wird dagegen eine Basis-Auftragsverwaltung beziehungsweise Order Management Lite ausgewiesen.
Salesforce Order Management Growth wird als weiteres Angebot mit zusätzlichen Funktionen für Distributed Order Management und Omnichannel Inventory beschrieben.
Diese Unterschiede sind für eine konkrete Architekturentscheidung relevant.
Sie belegen jedoch nicht automatisch, welche Funktionen ein Kunde unter seinem bestehenden Vertrag nutzen darf.
Die Salesforce-B2B-Dokumentation weist beispielsweise ausdrücklich auf eine erforderliche Order-Management-Lizenz für bestimmte B2B-Integrationsszenarien hin.
Die öffentlich beworbenen Editionsinhalte und die tatsächlich benötigten Produktberechtigungen müssen deshalb anhand der geltenden Verträge und Dokumentation geprüft werden.
Quelle: Salesforce Commerce Pricing & Editions.
Ein Beispiel für eine wirtschaftliche Architekturentscheidung
Ein B2B-Händler möchte seinen Kunden künftig ermöglichen, Auftragsstatus einzusehen, Lieferungen zu verfolgen und Retouren anzustoßen.
Ein Teil dieser Anforderungen könnte bereits durch bestehende Commerce- oder Order-Management-Funktionen abgedeckt werden.
Weitere Prozesse benötigen möglicherweise erweiterte OMS-Funktionen.
Gleichzeitig verfügt das Unternehmen bereits über ein ERP-System mit eigener Auftragsverwaltung.
Eine Entscheidung ausschließlich anhand der verfügbaren Salesforce-Produkte wäre in dieser Situation unzureichend.
Zunächst muss geklärt werden, welches System künftig die verbindlichen Auftragsdaten führt.
Anschließend ist zu prüfen, welche zusätzlichen Funktionen Salesforce tatsächlich bereitstellen soll.
Die Verwendung eines erweiterten Salesforce OMS kann sinnvoll sein, wenn dadurch wesentliche Prozesslücken geschlossen oder bestehende Integrationen vereinfacht werden.
Sie kann wirtschaftlich fragwürdig sein, wenn zentrale Prozesse bereits zuverlässig im ERP abgebildet werden und durch ein zusätzliches OMS vor allem neue Synchronisationsanforderungen entstehen.
Umgekehrt kann die alleinige Weiterverwendung des ERP aufwendig werden, wenn zahlreiche neue Vertriebskanäle und Fulfilment-Prozesse integriert werden müssen.
Die Lizenzentscheidung lässt sich deshalb nicht von der Architekturentscheidung trennen.
Umsatzabhängige und nutzungsabhängige Komponenten
Salesforce nutzt für Commerce je nach Produkt und Vertrag unterschiedliche kommerzielle Mechanismen, darunter auch umsatzbezogene Modelle.
Allgemeingültige Prozentsätze lassen sich aus den aktuellen öffentlichen Informationen jedoch nicht ausreichend belastbar ableiten.
Die im früheren Deep Dive enthaltenen pauschalen GMV-Sätze und Editionspreise werden deshalb nicht übernommen.
Bei Agentforce kommen weitere wirtschaftliche Mechanismen hinzu.
Salesforce veröffentlicht unter anderem Modelle auf Basis von Flex Credits und Konversationen.
Welche Kosten im konkreten Commerce-Einsatz entstehen, hängt jedoch vom verwendeten Agenten, den ausgeführten Aktionen, dem Vertragsmodell und möglichen ergänzenden Produkten ab.
Ein allgemeiner Agentforce-Preis ist damit nicht automatisch der Preis einer vollständigen agentengestützten Commerce-Transaktion.
Für eine wirtschaftliche Bewertung müssen tatsächliche Nutzungsszenarien modelliert werden.
Ein Agent, der vor allem Produktfragen beantwortet, erzeugt eine andere Kostenstruktur als ein Agent, der mehrere Systeme abfragt, Bestellungen vorbereitet, Daten verändert und Folgeprozesse auslöst.
Der vollständige Kostenrahmen
Die Gesamtkosten einer Salesforce-Commerce-Landschaft entstehen aus mehreren Ebenen.
Zur Plattformlizenz kommen Implementierung, Integration, Frontend-Entwicklung, individuelle Erweiterungen und Betrieb hinzu.
Abhängig von der gewählten Architektur können zusätzliche Salesforce-Anwendungen, externe Systeme und Integrationsdienste erforderlich sein.
Auch interne Fachbereiche verursachen Aufwand.
Produktdaten müssen gepflegt, Promotions gesteuert, Prozesse überwacht und Berechtigungen verwaltet werden.
Mit zunehmender Integration steigt häufig die Bedeutung übergreifender Architektur- und Governance-Kompetenz.
Deshalb ist die Total Cost of Ownership wichtiger als der isolierte Vergleich einer Commerce-Lizenz.
Total Cost of Change
Für langfristige Entscheidungen ist eine zweite Größe mindestens ebenso relevant.
Die Total Cost of Change beschreibt den wirtschaftlichen Aufwand, der entsteht, wenn sich Anforderungen verändern.
Dazu können neue Vertriebskanäle, internationale Märkte, andere Fulfilment-Modelle, neue Geschäftsbereiche oder zusätzliche Agentic-Commerce-Funktionen gehören.
Eine Architektur kann im laufenden Betrieb wirtschaftlich erscheinen und dennoch erhebliche Kosten verursachen, sobald größere Anpassungen notwendig werden.
Umgekehrt kann eine zunächst aufwendigere Integration langfristig sinnvoll sein, wenn sie eine stabile Grundlage für wiederkehrende Veränderungen schafft.
Diese Bewertung muss auf dem tatsächlichen Unternehmenskontext beruhen.
Vendor Lock-in differenziert betrachten
Salesforce verwendet proprietäre Commerce-Komponenten und Datenmodelle.
Dadurch können Wechselkosten entstehen.
Besonders relevant wird dies, wenn Geschäftslogik, Kundendaten, Integrationen und operative Abläufe eng mit mehreren Salesforce-Produkten verbunden sind.
Der Begriff Vendor Lock-in sollte allerdings nicht pauschal verwendet werden.
Technische Abhängigkeit, Datenportabilität, Vertragsbindung und organisatorisches Spezialwissen sind unterschiedliche Faktoren.
Eine tief integrierte Salesforce-Landschaft kann einen hohen Wechselaufwand verursachen und zugleich erheblichen wirtschaftlichen Nutzen erzeugen.
Entscheidend ist, ob dieser Nutzen die entstehenden Abhängigkeiten rechtfertigt.
Die wirtschaftliche Frage lautet nicht, ob Salesforce teuer oder günstig ist. Sie lautet, welche Gesamtarchitektur benötigt wird, welchen messbaren Nutzen sie schafft und wie viel zukünftige Handlungsfreiheit erhalten bleibt.
10. Entscheidungsreife: Wann Salesforce Commerce Cloud sinnvoll sein kann
Salesforce Commerce Cloud lässt sich nicht sinnvoll allein anhand der Unternehmensgröße beurteilen.
Eine internationale Handelsorganisation mit komplexen Kundenbeziehungen kann andere Anforderungen besitzen als ein Unternehmen mit vergleichbarem Umsatz, aber einem einfachen Direktvertriebsmodell.
Auch die bestehende IT-Landschaft spielt eine erhebliche Rolle.
Bestehende Salesforce-Investitionen
Unternehmen, die bereits Sales Cloud, Service Cloud oder weitere Salesforce-Anwendungen einsetzen, verfügen möglicherweise über technische und organisatorische Voraussetzungen, die den zusätzlichen Einsatz von Commerce Cloud erleichtern.
Vorhandene Kompetenzen, Datenmodelle und Integrationsstrukturen können genutzt werden.
Allerdings ist die bestehende Nutzung von Salesforce noch kein ausreichendes Argument für eine Commerce-Entscheidung.
Entscheidend ist, ob die konkreten Handelsprozesse tatsächlich von dieser Nähe profitieren.
Eine vorhandene CRM-Plattform kann den Kundenkontext verbessern. Sie ersetzt keine Analyse von Katalog-, Preis-, Checkout- und Fulfilment-Anforderungen.
B2C, B2B und hybride Geschäftsmodelle
Für umfangreiche B2C-Anforderungen bietet Salesforce eine etablierte Commerce-Architektur mit unterschiedlichen Storefront-Ansätzen und einem breiten Erweiterungsökosystem.
Für B2B kann die Nähe zur Salesforce Platform besonders dort relevant sein, wo Geschäftsbeziehungen, Account-Strukturen und Vertriebsprozesse eine zentrale Rolle spielen.
Bei kombinierten B2C-/B2B-Modellen muss die technische Trennung der Produktlinien dagegen ausdrücklich berücksichtigt werden.
Ein gemeinsames CRM und eine gemeinsame Commerce-Marke bedeuten nicht automatisch gemeinsame Preise, Bestände, Einkaufsberechtigungen oder Auftragsprozesse.
Agentic Commerce als Entscheidungskriterium
Die Entwicklung von Agentforce und offenen Commerce-Protokollen erweitert die strategische Perspektive.
Unternehmen müssen zunehmend entscheiden, welche Informationen und Transaktionen sie externen KI-Systemen zugänglich machen wollen.
Salesforce bietet hierfür relevante technische Möglichkeiten.
Der aktuelle Entwicklungsstand rechtfertigt jedoch keine pauschale Aussage, dass jeder Händler für Agentic Commerce einen vollständigen Salesforce-Stack benötigt.
Ebenso wenig sollte ein bestehender Händler allein wegen neuer Agentforce-Funktionen einen Plattformwechsel erwägen.
Zunächst muss überprüft werden, welche Anforderungen über vorhandene Commerce-APIs, zusätzliche Dienste oder gezielte Erweiterungen erfüllt werden können.
Die technologische Entwicklung begründet einen Prüfbedarf, nicht automatisch eine Migrationsentscheidung.
Wann eine grundlegende Architekturprüfung erforderlich wird
Eine vertiefte Plattform- oder Architekturentscheidung kann sinnvoll sein, wenn konkrete Geschäftsanforderungen durch strukturelle Grenzen wesentlich behindert werden.
Das kann etwa der Fall sein, wenn individuelle Prozesslogik nur mit unverhältnismäßigem Aufwand umgesetzt werden kann, Integrationen dauerhaft instabil bleiben oder erforderliche Geschäftsmodelle mit den verfügbaren Erweiterungsmechanismen nicht wirtschaftlich realisierbar sind.
Eine solche Situation muss jedoch nachgewiesen werden.
Unzufriedenheit mit einzelnen Funktionen, hohe Integrationskosten oder ein neuer technologischer Trend reichen für sich genommen nicht aus, um die Eignung einer gesamten Plattform infrage zu stellen.
Vor einem Plattformwechsel sind immer auch Erweiterungsoptionen, technische Modernisierung, Prozessvereinfachung und organisatorische Veränderungen zu untersuchen.
Die entscheidenden Managementfragen
Vor einer Einführung oder grundlegenden Weiterentwicklung von Salesforce Commerce Cloud sollten insbesondere folgende Fragen beantwortet sein.
Welche Systeme führen die verbindlichen Kunden-, Produkt-, Preis-, Bestands- und Auftragsdaten?
Welche Handelsprozesse müssen über B2C, B2B, Filialen und weitere Vertriebskanäle hinweg tatsächlich durchgängig funktionieren?
Welche Salesforce-Produkte sind dafür notwendig, welche lediglich optional und welche bestehenden Systeme können sinnvoll weiterverwendet werden?
Welche Agentic-Commerce-Funktionen sind im vorgesehenen Land, in der gewählten Edition und über die gewünschten Kanäle produktiv verfügbar?
Wo werden Geschäftsregeln, Einkaufsmandate und Zahlungsberechtigungen technisch durchgesetzt?
Welche laufenden Kosten, Integrationsabhängigkeiten und Veränderungsaufwände entstehen über mehrere Jahre?
Und schließlich: Verfügt das Unternehmen über die organisatorischen Fähigkeiten, diese Architektur nicht nur einzuführen, sondern dauerhaft zu steuern?
Diese Fragen liefern eine belastbarere Entscheidungsgrundlage als eine numerische Plattformbewertung.
Management-Fazit
Salesforce Commerce Cloud verfügt über eine umfangreiche technische und funktionale Basis für anspruchsvolle Handelsarchitekturen.
Das Unternehmen verbindet etablierte B2C- und B2B-Commerce-Produkte mit einem breiten Portfolio für Kundendaten, Auftragsmanagement, stationären Verkauf und KI-gestützte Prozesse.
Die Entwicklung von Agentforce und offenen Commerce-Protokollen schafft zusätzliche Möglichkeiten, Handelsfunktionen auch außerhalb klassischer Storefronts bereitzustellen.
Diese Möglichkeiten sind relevant. Sie sollten jedoch nicht mit einer bereits vollständig vereinheitlichten Handelsarchitektur verwechselt werden.
Die technische Trennung zwischen den Commerce-Produktlinien bleibt bestehen. Weitere Anwendungen müssen je nach Geschäftsprozess integriert werden. Agentic-Commerce-Funktionen unterscheiden sich hinsichtlich Verfügbarkeit, Prozessumfang und Governance.
Für eine Plattformentscheidung folgt daraus weder eine grundsätzliche Empfehlung noch eine grundsätzliche Einschränkung.
Salesforce Commerce Cloud kann eine tragfähige Grundlage für komplexe Handelsorganisationen bilden, wenn die vorhandenen Funktionen, Integrationen und Betriebsmodelle mit den tatsächlichen Anforderungen übereinstimmen.
Sie kann wirtschaftlich oder organisatorisch unangemessen werden, wenn der Nutzen der Gesamtarchitektur hinter dem Aufwand zurückbleibt, der für ihre Integration und Weiterentwicklung notwendig ist.
Die Qualität einer Commerce-Plattform zeigt sich nicht daran, wie überzeugend ihre Produkte gemeinsam vermarktet werden. Sie zeigt sich daran, wie zuverlässig Unternehmen ihre tatsächlichen Geschäftsprozesse damit betreiben und verändern können.
Quellen und Evidenzbasis
Recherchestand: 28. Oktober 2026
Diese Analyse stützt sich vorrangig auf offizielle Salesforce-Produktdokumentationen, Entwicklerunterlagen, Release-Informationen und veröffentlichte Preis- und Produktübersichten.
Herstellerangaben über Leistungsumfang, Verfügbarkeit und strategische Positionierung sind als solche zu verstehen. Die Schlussfolgerungen zu Architektur, Integration, Wirtschaftlichkeit und Entscheidungsreife sind unabhängige analytische Bewertungen.
Produktidentität und Portfolio
Salesforce: Commerce Cloud Product Overview
Aktuelle Produktbezeichnung, Portfolio und Herstellerpositionierung.
Salesforce: Commerce Cloud Pricing and Editions
Produkteditionen und öffentlich dokumentierte Leistungsumfänge.
Salesforce: Processor Binding Corporate Rules
Produktverzeichnis mit historischen Produktbezeichnungen und rechtlicher Einordnung.
B2C-Architektur und APIs
Salesforce Developers: Storefront Reference Architecture
SFRA-Architektur und Erweiterungsmodell.
Salesforce Developers: Composable Storefront
PWA Kit und Commerce-API-Anbindung.
Salesforce Developers: Why Use SCAPI
API-Strategie, technische Unterschiede und Migrationsempfehlungen.
Salesforce Developers: OCAPI Deprecation Policy
Deprecation seit April 2026 und geltende Unterstützungsbedingungen.
Salesforce Developers: OCAPI Settings
Einschränkungen für neue Realms seit September 2026.
B2B Commerce
Salesforce Help: Buyer Groups, Entitlements and Pricing
Kundenspezifische Sortimente, Berechtigungen und Preisstrategien.
Salesforce Help: Request for Quote
Angebotsprozesse und Verbindung zum Vertrieb.
Salesforce Help: Order Management and Omnichannel Inventory
Integration in B2B Commerce und dokumentierte Lizenz- und Funktionsgrenzen.
Agentic Commerce und externe Protokolle
Salesforce: Agentforce Commerce Release, Juli 2026
Herstellerankündigung zu Shopper Agent, Buyer Agent und Merchant Agent.
Salesforce Developers: B2C Commerce MCP Shopper Service
MCP-Funktionen und Pilotstatus.
Salesforce Developers: Universal Commerce Protocol Integration
GA-Status, Voraussetzungen, Integrationsumfang und Einschränkungen.
Salesforce Developers: UCP Configuration and Discovery
Business Profile, Protokollversionen und Konfiguration.
Salesforce Developers: UCP Implementation Considerations
Checkout-Hooks und individuelle Geschäftslogik.
Salesforce Developers: Enabling Google as a Platform
Merchant-Center-Anforderungen, Freischaltung und End-to-End-Tests.
Wirtschaftlichkeit
Salesforce: Commerce Cloud Preise und Editionen
Öffentlich dokumentierte Editionen und Preisabfrage.
Salesforce: Agentforce Pricing
Verbrauchsbasierte Abrechnungsmodelle.
Glossar
Agentforce: Salesforce-Plattform und Produktfamilie für die Entwicklung und Ausführung KI-gestützter Agenten innerhalb unterschiedlicher Geschäftsprozesse.
Agentic Commerce: Handelsprozesse, bei denen KI-Agenten Informationen abrufen, Entscheidungen vorbereiten oder autorisierte Aktionen bis hin zu Transaktionen ausführen.
ACP (Agentic Commerce Protocol): Protokollansatz zur strukturierten Integration von Commerce-Funktionen in KI-basierte Einkaufsumgebungen, insbesondere im Umfeld von OpenAI und Stripe.
B2C Commerce: Salesforce-Commerce-Produktlinie für den Verkauf an Endkunden mit technischer Herkunft aus Demandware.
B2B Commerce: Salesforce-Commerce-Produktlinie für Geschäftskunden und accountbasierte Beschaffungsprozesse mit historischer Herkunft aus CloudCraze.
Buyer Group: Gruppierung von Geschäftskäufern zur Steuerung von Produktzugang und Preisen in Salesforce B2B Commerce.
Composable Storefront: Entkoppelter Salesforce-Frontend-Ansatz auf Basis von PWA Kit und Managed Runtime.
Data 360: Salesforce-Datenplattform zur Verbindung und Nutzung von Daten aus unterschiedlichen Quellen, vormals Data Cloud.
Entitlement Policy: Regelwerk zur Steuerung der Sichtbarkeit und Zugänglichkeit von Produkten für bestimmte Käufergruppen.
MCP (Model Context Protocol): Protokoll zur strukturierten Bereitstellung von Werkzeugen und Informationen für KI-Anwendungen.
OCAPI (Open Commerce API): Ältere API-Familie von Salesforce B2C Commerce, seit April 2026 deprecated.
SCAPI (Salesforce Commerce API): Von Salesforce für neue B2C-Commerce-Integrationen vorgesehene API-Familie.
SFRA (Storefront Reference Architecture): Salesforce-Referenzarchitektur für serverseitig gerenderte B2C-Storefronts mit einem Controller- und Cartridge-Modell.
SLAS (Shopper Login and API Access Service): Salesforce-Dienst für Authentifizierung und autorisierten Zugriff auf Commerce-Funktionen.
UCP (Universal Commerce Protocol): Offener Protokollansatz für die interoperable Kommunikation zwischen Handelsplattformen und externen Anwendungen oder KI-Agenten.
Unified Commerce: Organisatorisch und technisch durchgängige Verbindung von Handelskanälen, Kundeninformationen, Beständen, Auftragsprozessen und Service.
WebMCP: Ansatz zur Bereitstellung von Website-Funktionen als strukturierte Werkzeuge für KI-Agenten. Eine konkrete allgemeine Salesforce-Commerce-Unterstützung ist zum Recherchestichtag nicht hinreichend belegt.
Über den Autor
Andreas Rieger ist unabhängiger E-Commerce- und AI-Berater mit mehr als 20 Jahren Erfahrung im digitalen Handel. Er unterstützt Unternehmen bei Plattformentscheidungen, Commerce-Architekturen und der organisatorischen Integration digitaler Geschäftsprozesse.
Seine Analysen erfolgen ohne Herstellerbindung und ohne bevorzugte Implementierungsplattform.