Ein B2B-Store oder mehrere: Länder, Marken, Händler

Die meisten Hersteller brauchen in Salesforce B2B Commerce einen Store pro Marke oder pro Gesellschaft mit eigenem Checkout und für alles andere Käufergruppen. Länder und Händlerstufen rechtfertigen selten einen eigenen Store: Ein Store schafft bis zu 25 Sprachen, Warenkörbe in der Währung des Käufers und unterschiedliche Sortimente und Preise über Käufergruppen. Ein zweiter Store wird nötig, wenn Katalogstruktur, Auftritt, Checkout oder das ERP dahinter wirklich abweichen. Jeder weitere Store vervielfacht Inhalte, Tests und Release-Aufwand, und die Editionen enthalten nur 6 (Growth) oder 10 (Advanced) Storefronts.

Was entscheidet über die Zahl der B2B-Stores?

Der Store ist die Nabe von Salesforce B2B Commerce, das Salesforce laut Trailhead1 inzwischen auch als “Agentforce Commerce for B2B” vermarktet. Um den Store herum liegen Katalog, Käufergruppen (Buyer Groups), Entitlement Policies und Preisbücher. Trailhead zum Datenmodell2 beschreibt das als Speichen um eine Nabe und sagt, dass ein Unternehmen mehrere Stores für verschiedene Geschäftsbereiche oder Regionen anlegen kann.

Drei Objekte entscheiden, ob ein Store reicht:

• Käufergruppen verbinden Käuferkonten mit einem Store. Ein Store kann viele Käufergruppen haben, und jede Gruppe bekommt eigene Entitlement Policies und Preisbücher.
• Entitlement Policies legen fest, welche Produkte eine Käufergruppe sehen und kaufen darf.
• Der Katalog enthält den Kategoriebaum und die Produkte. Ein Store hat genau einen Katalog, laut Produkt- und Katalogdatenmodell3 kann derselbe Katalog aber mehrere Stores bedienen.

Der Store ist also die Einheit für alles, was Käufer als “den Shop” erleben: Auftritt, Domain, Katalogstruktur, Checkout und die Logik dahinter. Wer was zu welchem Preis sieht, entscheidet sich eine Ebene tiefer, in den Käufergruppen. Wie man sie schneidet, steht in Buyer Groups und Entitlements.

25 Sprachen, ein Katalog, fünf Preisbücher pro Store

Diese Limits stammen von den Salesforce-Developers-Seiten zu Store-Limits4, Produkt-Limits5, Preisbuch-Limits6 und Käufergruppen-Limits7, Stand Oktober 2026:

Limit	Wert	Art
B2B-Stores pro Org	100	fest
Kataloge pro Store	1	fest
Sprachen pro Store	25	weich
Preisbücher, die einem Store zugeordnet sind	5	fest
Preisbücher pro Käufergruppe	50 in der Tabelle, 25 in einem Hinweis	weich
Käufergruppen pro Käuferkonto	20 (30 mit Apex-Extension)	weich
Produkte pro Store	4 Millionen, davon 1 Million durchsuchbar	fest

Weiche Limits hebt der Salesforce-Support auf Anfrage an, feste nicht. Die 100 Stores sind für jeden Hersteller, den ich mir vorstellen kann, weit weg. Früher greifen der eine Katalog und die fünf Store-Preisbücher. Eine Marke, die einen eigenen Kategoriebaum braucht, bekommt ihn in einem gemeinsamen Store nicht, und eine Preisstruktur mit vielen Listen gehört in Käufergruppen-Preisbücher statt in Store-Preisbücher. Woher die Preise selbst kommen sollten, behandelt Kundenpreise: Preisbücher oder ERP.

Wann reicht ein Store mit Käufergruppen?

Für Länder in den meisten Fällen. Sprachen werden pro Store eingestellt, bis zu 25. Zu Währungen sagt der Developer Guide zu Währungswechseln8, dass der Warenkorb die Standardwährung des Kontos nutzt und Produkte und Preisbücher für jede Währung eingerichtet sein müssen, die der Store unterstützt. Ein Händler in der Schweiz und einer in Deutschland können also im selben Store in CHF und EUR kaufen. Ein Detail zählt fürs Design: Warenkörbe unterstützen keinen automatischen Währungswechsel, und Salesforce empfiehlt, die Währungsauswahl abzuschalten, sobald ein Artikel im Warenkorb liegt.

Für Händlerstufen ebenfalls. Eine Käufergruppe pro Stufe, jede mit eigenem Preisbuch, deckt Gold-, Silber- und Standardhändler ab. Ob ein Käufer mit mehreren Preisbüchern den niedrigsten Preis sieht oder den aus dem Preisbuch mit der höchsten Priorität, ist laut Salesforce-Hilfe zu Preisstrategien9 eine Store-Einstellung: Best Price oder Priority Price.

Auch für Ländersortimente. Ein Teil, das in einem Land nicht verkauft werden darf, bleibt einfach aus der Entitlement Policy dieses Landes heraus.

Meine Regel für den Schnitt: Käufergruppen nach Land und Händlerstufe, nie eine Gruppe pro Konto. Bei 2.000 Buyer Entitlements pro Produkt10 als festem Limit wird ein Teil, das 3.000 einzeln gruppierte Händler kaufen dürfen, nur für die ersten 2.000 Gruppen indexiert, der Rest findet es in der Suche nicht.

Wann lohnt sich ein zweiter Store?

Einen zweiten Store würde ich in vier Fällen einplanen:

1. Eine andere Marke mit eigenem Auftritt. Jeder Store wird im Experience Builder gestaltet, und die Hilfe zu B2B Commerce11 führt eigene Domain und Veröffentlichung als Schritte pro Store. Ein Händler der Marke B sollte sich nicht in einem Shop anmelden, der wie Marke A aussieht.
2. Eine andere Katalogstruktur. Ein Katalog pro Store heißt ein Kategoriebaum. Sortiert Marke B ihre Teile nach Maschinenbaureihe und Marke A nach Funktion, brauchen sie zwei Kataloge und damit zwei Stores.
3. Ein anderer Checkout oder ein anderes ERP. Commerce Extensions für Preise, Bestand, Steuer oder Auftragsanlage werden laut Extensions Guide12 mit sf commerce:extension:map einem Store zugeordnet. Eine Gesellschaft, die aus einem anderen ERP verkauft, braucht andere Aufrufe und läuft einfacher als eigener Store.
4. Andere Käufer. Laut Hilfe kann ein Unternehmen einen B2B- und einen D2C-Kanal aus einer Org mit gemeinsamen Daten betreiben. Endkunden neben Händlern bedeuten also einen eigenen D2C-Store, bei geteilten Produktdaten.

Teilen sich zwei Marken die meisten Teile, hilft der gemeinsame Katalog: zwei Storefronts, ein Satz Produktdaten.

Jeder weitere Store kostet Pflege nach jedem Release

Die Lizenzseite ist kurz. Die B2B-Preisseite13 nennt 6 Storefronts in Growth und 10 in Advanced und keinen Preis für weitere. Kommt Ihre Planung in die Nähe, gehören die Zahl der Storefronts und der Preis für zusätzliche in den Vertrag. Die GMV-Gebühr fällt auf den Umsatz über die Storefronts an, ein zweiter Store ändert sie also nur, wenn er neue Bestellungen bringt, siehe B2B Commerce Preise und das GMV-Modell.

Die Aufwandsseite ist länger. Jeder Store hat eigene Seiten, Navigation, Übersetzungen, Extension-Zuordnungen und Einstellungen. Nach jedem der drei Salesforce-Releases im Jahr braucht jeder Store seinen Regressionstest, und jede eigene Komponente wird in jedem Store getestet, der sie nutzt. Wie man diesen Rhythmus plant, steht im DevOps-Kapitel zur Release-Planung. Zwei Stores sind nicht doppelt so viel Arbeit wie einer, aber deutlich mehr als ein Store mit zwei Käufergruppen.

Rechenbeispiel: zwei Marken in 14 Ländern

Angenommen, ein Maschinenbauer verkauft Ersatzteile unter zwei Marken. Marke A ist in 9 Ländern vertreten, Marke B, vor einigen Jahren zugekauft, in 5 Ländern. Marke B läuft noch auf einem eigenen ERP-Mandanten. Die Händler von Marke A haben drei Stufen, die von Marke B zwei.

Ein Store pro Land wären 14 Stores, mehr als die 10 Storefronts in Advanced und 14 Regressionstests pro Release. Ein Store für alles würde Händler der Marke B in einen Shop mit dem Auftritt und den ERP-Aufrufen von Marke A setzen.

Der Schnitt im Szenario: zwei Stores, einer pro Marke. Marke A bekommt Käufergruppen pro Land und Stufe, 27 insgesamt, Marke B 10. Jedes Käuferkonto steckt in ein oder zwei Gruppen, weit unter den 20 pro Konto. Einen gemeinsamen Katalog nutzen beide Stores nur, wenn die Kategoriebäume passen. Im Szenario tun sie das nicht, es gibt also zwei Kataloge. Zwei Stores passen bequem in die 6 Storefronts von Growth.

Das folgt derselben Logik wie ein weltweiter Rollout von Manufacturing Cloud: Die Marke ist vom ersten Tag an eine Frage für das Template, auch wenn das erste Land nur eine hat.

Erster Schritt: Marken, ERP-Mandanten und Länder auf eine Seite

1. 01

   Alles auf eine Seite

   Eine Zeile pro Marke, Gesellschaft, ERP-Mandant, Land, Währung, Sprache und Händlerstufe.

2. 02

   Echte Unterschiede markieren

   Nur Zeilen, die sich in Auftritt, Katalogstruktur, Checkout oder ERP unterscheiden, bekommen einen eigenen Store. Alles andere wird eine Käufergruppe.

3. 03

   Limits prüfen

   Sprachen pro Store, Store-Preisbücher und Käufergruppen pro Käuferkonto gegen die Tabelle oben zählen.

4. 04

   Das Kaufmännische klären

   Zahl der Storefronts und Preis für weitere schriftlich festhalten.

Das Kapitel Katalog, Suche, Sichtbarkeit der Masterclass B2B Commerce ordnet diese Entscheidung in das gesamte Store-Design ein. Wie ich solche Schnitte angehe, beschreibe ich unter Salesforce-Architektur.

Quellen13

1. 1Trailhead (öffnet in einem neuen Tab)trailhead.salesforce.com
2. 2Trailhead zum Datenmodell (öffnet in einem neuen Tab)trailhead.salesforce.com
3. 3Produkt- und Katalogdatenmodell (öffnet in einem neuen Tab)developer.salesforce.com
4. 4Store-Limits (öffnet in einem neuen Tab)developer.salesforce.com
5. 5Produkt-Limits (öffnet in einem neuen Tab)developer.salesforce.com
6. 6Preisbuch-Limits (öffnet in einem neuen Tab)developer.salesforce.com
7. 7Käufergruppen-Limits (öffnet in einem neuen Tab)developer.salesforce.com
8. 8Währungswechseln (öffnet in einem neuen Tab)developer.salesforce.com
9. 9Salesforce-Hilfe zu Preisstrategien (öffnet in einem neuen Tab)help.salesforce.com
10. 102.000 Buyer Entitlements pro Produkt (öffnet in einem neuen Tab)developer.salesforce.com
11. 11Hilfe zu B2B Commerce (öffnet in einem neuen Tab)help.salesforce.com
12. 12Extensions Guide (öffnet in einem neuen Tab)developer.salesforce.com
13. 13B2B-Preisseite (öffnet in einem neuen Tab)salesforce.com