Salesforce Experience Cloud als Full-Stack-Plattform

Einleitung

Moderne Webanwendungen folgen meist einem vertrauten Stack: Frontend, Backend, Datenbank, Identity Provider, Hosting, Jobs, Suche, Observability, Deployment und Integrationen.

Salesforce bietet für eine bestimmte Klasse von Anwendungen einen anderen Weg. Mit Experience Cloud, Lightning Web Components (LWC), Apex, Salesforce-Objekten, Flow, Identität, Freigaben (Sharing), Automatisierung und Integrationen können Teams vollständige Webanwendungen für Kunden, Partner und Mitarbeitende auf einer einzigen verwalteten Plattform entwickeln.

Entscheidend ist die Formulierung „bestimmte Klasse von Anwendungen“. Experience Cloud ist dort am stärksten, wo die Webanwendung mit Salesforce-Daten, Workflows, Benutzern und Geschäftsprozessen verbunden ist. Sie ersetzt nicht jeden individuellen Web-Stack, kann aber weit mehr abdecken als ein einfaches Portal.

Experience Cloud eignet sich für Produktkataloge, shopähnliche Storefronts, Partner-Onboarding, Händler-Dashboards, Buchungsportale, Serviceanfragen, Abo-Dashboards, Kunden-Self-Service, Lernportale, Fallverfolgung, Schadensmeldungen, Statusseiten für Anträge und operative Tools.

Bei Consumer-Commerce im großen Maßstab, Streaming, suchlastigen Katalogen, spezialisierten Transaktions-Engines oder ungewöhnlichen Infrastrukturanforderungen ist Salesforce oft nur ein Teil einer größeren Architektur. Salesforce Commerce, einschließlich B2B- und D2C-Commerce-Storefronts auf Basis der Lightning Web Runtime (LWR), kann dabei Teil der Experience-Cloud-Lösung sein statt einer separaten Website. Die Entscheidung hängt vom benötigten Produkt, der Lizenz, der Skalierung, dem Datenmodell und dem Integrationsmuster ab.

Architekturüberblick: Experience Cloud als Full-Stack

Eine Full-Stack-Anwendung braucht eine Benutzeroberfläche, serverseitige Logik, Datenhaltung, Identität, Zugriffskontrolle, Automatisierung, Integrationen, Deployment und Betrieb.

In einer Salesforce-zentrierten Architektur verteilen sich diese Aufgaben in der Regel wie folgt. Im Diagramm steht LDS für Lightning Data Service und UI API für User Interface API.

Dies ist eine logische Architektur. Nicht jede Anfrage läuft über Apex oder Flow. Eine datensatzorientierte Seite kann Standardkomponenten, LDS oder UI API nutzen. Eine individuelle Such- oder Checkout-Erfahrung benötigt unter Umständen LWC, Apex, Flow, Platform Events, Commerce-APIs oder Middleware.

Die zentrale Architekturfrage ist die Verantwortung: Welche Ebene ist für Darstellung, Validierung, Datenzugriff, Autorisierung, Integration und Betrieb zuständig?

Experience Cloud und LWR

Experience Cloud stellt die Oberfläche der Webanwendung bereit. Je nach Vorlage und Anwendungsfall kann eine Site öffentliche Seiten, authentifizierte Seiten, Partnerbereiche, Self-Service-Seiten für Kunden, CMS-Inhalte, Datensatzseiten, Dashboards, eigene Flows und eigene Komponenten enthalten.

LWR-Sites sind Experience-Cloud-Sites, die auf der Lightning Web Runtime laufen. Sie sind nicht dasselbe wie eine eigenständige LWR-App auf Node.js. In Experience Cloud ist LWR die verwaltete Salesforce-Runtime hinter Vorlagen wie Build Your Own (LWR) und Microsite (LWR) und unterstützt individuelle Erlebnisse mit Lightning Web Components. LWR-Sites unterstützen keine Aura-Komponenten. Wählen Sie daher eine Aura-Vorlage, wenn die Site auf eigene Aura-Komponenten oder Funktionen angewiesen ist, die es nur in Aura gibt.

Mit Experience Builder stellen Admins und Entwickler Seiten visuell aus Vorlagen und Komponenten zusammen. Eine gute Experience-Cloud-Anwendung kombiniert in der Regel deklarative Gestaltung mit eigenen Komponenten: Experience Builder für die Struktur, eigene LWC dort, wo Interaktion, Datenform oder Workflow ein individuelles Verhalten erfordern.

Lightning Web Components als Frontend

Lightning Web Components bilden die individuelle Frontend-Ebene. LWC nutzt moderne Webstandards, HTML-Templates, JavaScript-Module, CSS, Komponenteneigenschaften, Lifecycle-Hooks, Events und Salesforce-spezifische Module.

In einer Experience-Cloud-Anwendung kann LWC Produktkarten, Listenraster, Suchfilter, Ergebnisseiten, Formulare, Statusanzeigen, Partner-Dashboards, Datentabellen, Datensatzübersichten, eigene Navigation, Layout-Komponenten und wiederverwendbare Workflow-Widgets übernehmen.

Für den Datenzugriff nutzen Sie LDS und UI API, wo sie passen, vor allem für datensatzorientierte Oberflächen, die Salesforce-Metadaten und das Sicherheitsverhalten der Plattform berücksichtigen sollen. Apex setzen Sie für eigene Abfragen, Aggregationen, Geschäftsregeln, Orchestrierung, externe Callouts oder eine Serviceschicht ein, die Implementierungsdetails vor dem Browser verbirgt.

Eine Produktkatalog-Komponente kann etwa Produktnamen, Beschreibungen, Bilder und Preise anzeigen und dabei Lade- und Fehlerzustände behandeln. Im Produktivbetrieb braucht sie zusätzlich Barrierefreiheit, Paginierung, Caching, Tests und ein maßgebliches Backend für Preise und Verfügbarkeit.

Das Frontend ist für Darstellung und Benutzerinteraktion zuständig. Es sollte weder Datenbank-Zugangsdaten noch Autorisierungsregeln, die verbindliche Preisprüfung, Bestandsprüfungen oder endgültige Geschäftsentscheidungen verantworten.

Apex und Flow als Backend

Apex ist die serverseitige Programmiersprache von Salesforce. Sie ist streng typisiert, objektorientiert und darauf ausgelegt, Geschäftslogik auf der Salesforce Platform auszuführen. Apex kann Daten mit SOQL abfragen, mit DML ändern, Methoden für Lightning-Komponenten bereitstellen, asynchrone Jobs ausführen, REST-Endpunkte definieren und HTTP-Callouts durchführen.

In einer Experience-Cloud-Anwendung übernimmt Apex häufig die Rolle der Serviceschicht:

• Daten für eigene Oberflächen lesen und aufbereiten.
• Geschäftsregeln vor Schreibvorgängen prüfen.
• Transaktionen über mehrere Datensätze koordinieren.
• Sensible Vorgänge vor direkter Steuerung durch den Client schützen.
• Zahlungs-, Versand-, ERP-, Steuer- oder Suchdienste aufrufen.
• Platform Events veröffentlichen oder asynchrone Verarbeitung einreihen.
• Bei Bedarf eigene REST-Endpunkte bereitstellen.

Flow ergänzt Apex. Setzen Sie Flow ein, wenn sich der Prozess als Entscheidungen und Aktionen verstehen lässt, wenn Admins die Logik verantworten sollen und wenn die Automatisierung zu den unterstützten Flow-Funktionen passt. Apex ist die bessere Wahl, wenn Logik bulkifiziert, wiederverwendbar, transaktionsbewusst oder integrationslastig sein oder zentral getestet werden muss.

Die stärkste Architektur nutzt oft beides. Flow orchestriert den Geschäftsprozess, Apex übernimmt spezialisierte Logik. Queueable Apex, Future-Methoden, Platform Events oder Middleware entkoppeln lang laufende Vorgänge von der Benutzeranfrage.

Apex-Sicherheit: User Mode ist jetzt Standard

Ab API-Version 67.0, eingeführt mit Summer ‘26, haben sich die Sicherheitsstandards von Apex in wichtigen Punkten geändert.

• Apex-Datenbankoperationen, einschließlich SOQL, SOSL, DML und Database-Methoden, laufen standardmäßig im User Mode. Sie setzen die Objektberechtigungen, die Sicherheit auf Feldebene (Field-Level Security, FLS) und die Freigaberegeln des ausführenden Benutzers durch, sofern die Operation nicht ausdrücklich im System Mode ausgeführt wird.
• Klassen ohne Sharing-Schlüsselwort laufen im Kontext des aktuellen Benutzers. Salesforce empfiehlt für die Wartbarkeit weiterhin explizite Deklarationen mit with sharing, without sharing oder inherited sharing.
• Ab API-Version 67.0 ist WITH SECURITY_ENFORCED in SOQL innerhalb von Apex nicht mehr zulässig. Code, der es in dieser API-Version verwendet, lässt sich nicht kompilieren. Verwenden Sie stattdessen WITH USER_MODE.
• Bis einschließlich API-Version 66.0 laufen Apex-Datenbankoperationen standardmäßig im System Mode. Entwickler müssen Objektberechtigungen und FLS dort also bewusst durchsetzen, wo es nötig ist.

Es handelt sich um eine versionierte Verhaltensänderung. Sie bedeutet nicht, dass sich jeder Apex-Pfad sicherheitstechnisch gleich verhält. Klassen-Sharing, Zugriffsmodus der Operation, Trigger, Gastbenutzer, Berechtigungssätze und der Zugriff auf Apex-Klassen müssen weiterhin bewusst geprüft werden.

Für Experience-Cloud-Code gilt:

• Sharing-Deklarationen bewusst setzen.
• WITH USER_MODE, WITH SYSTEM_MODE und Zugriffsoptionen für Datenbankmethoden verwenden, wo die Absicht eindeutig sein soll.
• Für Standard-Datensatzoberflächen LDS oder UI API bevorzugen, wenn sie passen.
• Jede @AuraEnabled-Methode wie einen Service-Endpunkt behandeln.
• Zugriff auf Apex-Klassen nur den Profilen oder Berechtigungssätzen gewähren, die ihn brauchen.
• Zugriff für authentifizierte Benutzer und Gastbenutzer getrennt testen.

Clientseitige Prüfungen verbessern die Bedienbarkeit. Eine Sicherheitsgrenze sind sie nicht.

Salesforce-Daten und Commerce

In einer klassischen Anwendung modellieren Teams Daten häufig in PostgreSQL, MySQL, MongoDB, DynamoDB oder einer anderen Datenbank. In Salesforce lassen sich die Kerndaten vieler Geschäftsanwendungen mit Standard- und benutzerdefinierten Objekten abbilden.

Für eine shopähnliche Anwendung könnte ein vereinfachtes Modell so aussehen:

Salesforce-Objekt	Zweck
Account	Kunde, Haushalt, Lieferant oder Geschäftskunde
Contact	Person, die einem Account zugeordnet ist
Product2	Produktdatensätze und Katalogattribute
PricebookEntry	Preis eines Produkts in einem Preisbuch
Order und OrderItem	Auftragskopf und Positionen, je nach gewähltem Auftragsmodell
Benutzerdefinierte Objekte	Warenkorb, Buchung, Antrag, Berechtigung oder domänenspezifische Workflow-Datensätze

Manche vereinfachten Katalogmodelle verwenden Product2 mit einem benutzerdefinierten Feld Price__c, damit das Konzept leicht nachvollziehbar bleibt. Das ist keine vollständige Commerce-Implementierung. Eine echte Lösung muss festlegen, wie Preise ausgewählt und geprüft werden, wie Bestände und Reservierungen funktionieren, wie Steuern und Versand berechnet werden, wie Checkout und Zahlungen ablaufen und wie Aufträge in die Abwicklung gelangen.

Diese Fähigkeiten können aus Salesforce Commerce, eigener Salesforce-Logik oder integrierten Diensten stammen. B2B- und D2C-Commerce-Stores lassen sich mit LWR-Vorlagen erstellen und mit Commerce-LWCs und Storefront-APIs anpassen. Commerce kann damit nativer Bestandteil der Experience-Cloud-Implementierung sein und keine losgelöste externe Ebene.

Nutzen Sie Data 360, ehemals Data Cloud, wenn die Anwendung einheitliche Kundenprofile, Datenaufnahme, Harmonisierung, Aktivierung oder datengestützte Personalisierung über mehrere Quellen hinweg benötigt. Am 14. Oktober 2025 hat Salesforce Data Cloud in Data 360 umbenannt. Ältere Dokumentation und Produktoberflächen können während der Umstellung noch den Namen Data Cloud enthalten.

Der Kompromiss: Salesforce ist keine uneingeschränkte Datenbank-Engine. Architekten müssen Speicher, Governor Limits, Abfrageselektivität, große Datenmengen, die Komplexität von Eigentümerschaft und Sharing, Lizenzen für externe Benutzer, API-Limits, Suche, Transaktionsgrenzen und Compliance berücksichtigen.

Identität und Autorisierung in Experience Cloud

Eine ernstzunehmende Webanwendung muss zwei getrennte Fragen beantworten:

• Wer ist dieser Benutzer?
• Was darf dieser Benutzer tun?

Experience Cloud unterstützt externe Benutzer und arbeitet mit Salesforce Identity und unterstütztem Single Sign-on zusammen. Sobald Benutzer authentifiziert sind, entscheiden die Autorisierungskontrollen von Salesforce, worauf sie zugreifen dürfen.

Zu diesen Kontrollen gehören Profile, Berechtigungssätze, Objektberechtigungen, FLS, Freigaben auf Datensatzebene, Sharing Sets, Freigaberegeln, externe organisationsweite Standardeinstellungen, Share Groups, Super-User-Zugriff, Restriction Rules, Zugriff auf Apex-Klassen, Flow-Zugriff und serverseitige Prüfungen in Apex.

Das Freigabedesign hängt stark von der Lizenz für externe Benutzer ab:

• Customer Community und andere nicht rollenbasierte Modelle für hohe Benutzerzahlen setzen häufig auf Sharing Sets und Share Groups.
• Benutzer mit Customer Community Plus und Partner Community arbeiten mit Rollen und Standard-Freigabefunktionen wie Freigaberegeln, Rollenhierarchie und externer Account-Hierarchie.
• Externe organisationsweite Standardeinstellungen helfen, für authentifizierte externe Benutzer einen strengeren Standardzugriff festzulegen als für interne Benutzer.
• Gastbenutzer sind keine authentifizierten externen Benutzer. Ihr Zugriff muss separat konzipiert und als öffentlicher Zugriff behandelt werden.

Für öffentliche oder gemischt öffentlich-authentifizierte Sites gilt: nur den minimal nötigen Zugriff gewähren, breite Objektberechtigungen für Gastbenutzer vermeiden, den Zugriff auf @AuraEnabled einschränken, alle Benutzereingaben validieren und keine sensiblen Felder an den Browser übergeben.

Integrationen

Die meisten Full-Stack-Anwendungen müssen mit Zahlungsanbietern, Steuerdiensten, ERP-Systemen, Fulfillment-Systemen, Dokumentenplattformen, Analyse-Tools, Marketingsystemen oder eigenen APIs kommunizieren.

Gängige Integrationsmuster in Salesforce sind:

• Apex-Callouts für Request-Reply-Integrationen, wenn der Benutzer oder die Transaktion gefahrlos warten kann.
• Queueable Apex oder Future-Methoden für asynchrone Callouts, die den Benutzerpfad nicht blockieren sollen.
• Named Credentials und External Credentials für die unterstützte Konfiguration von Endpunkten und Authentifizierung.
• Salesforce-APIs für externe Systeme, die Salesforce aufrufen.
• Platform Events und Change Data Capture für ereignisgesteuerte Integration.
• Bulk API 2.0 für große Datenbewegungen.
• Middleware für Orchestrierung, Transformation, Wiederholungsversuche, Monitoring und systemübergreifende Zuverlässigkeit.
• Datenvirtualisierung, etwa mit Salesforce Connect, wo es passt.

Für einfache Interaktionen können Apex-Callouts genügen. Bei komplexer Orchestrierung, vor allem wenn Wiederholungsversuche, Reihenfolge, Transformation oder systemübergreifende Zuverlässigkeit wichtig sind, ist Middleware oft die sauberere Grenze.

Agentforce in Experience Cloud

Heute sollten die meisten Experience-Cloud-Architekturen Agentforce zumindest prüfen. Experience-Cloud-Sites können Agentforce-Service-Agenten über Enhanced Chat einbinden, den aktuellen Messaging-Kanal von Salesforce, der früher Messaging for In-App and Web hieß. Für KI-gestützte Self-Service-Szenarien lässt sich zudem Agentforce Orchestrator nutzen, sofern diese Funktionen lizenziert und konfiguriert sind.

Agentforce kommt damit nicht automatisch. Es wirft neue Architekturfragen auf:

• Welche Benutzer sind anonym, verifiziert oder authentifiziert?
• Welche Benutzer- oder Agentenidentität greift auf Salesforce-Daten zu?
• Welche Aktionen darf der Agent auslösen?
• Welche Daten stammen aus Knowledge, CRM-Datensätzen, Data 360 oder externen Systemen?
• Wie werden Konversationen getestet, überwacht und eskaliert?
• Welches Lizenz- und Verbrauchsmodell gilt?

Für Kunden-Self-Service kann Agentforce eine wertvolle Ebene über Experience Cloud sein. Es braucht aber dieselbe Disziplin bei der Zugriffskontrolle wie Apex, Flow und LWC.

Deployment und Lebenszyklus

Auch Experience-Cloud-Anwendungen brauchen eine saubere Softwareauslieferung. Salesforce betreibt die Hosting-Infrastruktur, doch die Teams bleiben für sichere Releases, Zugriffskonfiguration, Tests, Monitoring und Rollback-Planung verantwortlich.

Zu einem gesunden Auslieferungsmodell gehören Versionskontrolle, Salesforce CLI, Sandboxes oder Scratch Orgs, Metadaten-Deployment, Apex-Tests, LWC-Tests wo sinnvoll, Prüfung von Berechtigungen und Freigaben, Prüfungen bei der Site-Veröffentlichung, umgebungsspezifische Konfiguration, Smoke-Tests sowie Monitoring für Integrationsfehler und asynchrone Jobs.

Auch die Metadaten von Experience Cloud verlangen besondere Sorgfalt. Je nach Site-Typ und Vorlage umfasst ein Deployment ExperienceBundle, DigitalExperienceBundle- oder DigitalExperience-Metadaten, Network, CustomSite, CMS-Inhalte, Commerce-Metadaten, Berechtigungssätze, Apex, LWC und unterstützende Objekte. LWR-Sites nutzen quellcodefreundliche Metadaten, doch nicht jede Site-Einstellung und jede betriebliche Abhängigkeit wird automatisch erfasst. Validieren Sie immer zuerst in einer Sandbox, bevor Sie in Produktion gehen.

Klassischer Web-Stack im Vergleich zu Salesforce

Aufgabe	Klassischer Stack	Salesforce-zentrierter Ansatz
Site-Gerüst und Routing	Web-Framework oder Frontend-Router	Experience Cloud, Experience Builder, LWR
Individuelles Frontend	React, Angular, Vue	Lightning Web Components
Designsystem	CSS-Framework oder eigenes Designsystem	Salesforce Lightning Design System (SLDS), Basiskomponenten, eigenes CSS
Backend-Dienste	Node.js, Java, .NET, Python	Apex, Flow, Invocable Actions, REST-Ressourcen
Datenbank	PostgreSQL, MySQL, MongoDB	Standard- und benutzerdefinierte Objekte, SOQL, DML
Datenzugriff für Datensatzoberflächen	Eigene API und ORM	LDS, UI API
Geschäftsautomatisierung	Jobs, Worker, Workflow-Engines	Flow, Apex, asynchrones Apex, Platform Events
Authentifizierung	Identity Provider und Middleware	Salesforce Identity und Authentifizierung externer Benutzer
Autorisierung	Anwendungsrichtlinien und Datenbankberechtigungen	Profile, Berechtigungssätze, Sharing, FLS, Apex-Prüfungen
Integrationen	HTTP-Clients, Queues, Middleware	Apex-Callouts, Salesforce-APIs, Events, Middleware
Deployment	CI/CD in eine Cloud-Runtime	Metadaten-Deployment, Salesforce CLI, DevOps-Tools
Hosting	Cloud-Infrastruktur	Von Salesforce verwaltetes Plattform-Hosting

Diese Übersicht ordnet Verantwortlichkeiten zu. Sie ist keine Eins-zu-eins-Entsprechung. Nutzen Sie die Plattform dort, wo sie zur Last, zum Sicherheitsmodell, zum Kostenmodell und zu den betrieblichen Anforderungen passt.

Wann Experience Cloud die richtige Wahl ist

Experience Cloud ist ein starker Kandidat, wenn die Anwendung:

• Kunden, Partner, Mitglieder, Lieferanten, Studierende oder Mitarbeitende bedient.
• Sicheren Zugriff auf Salesforce-Datensätze und Workflows braucht.
• Von Salesforce Identity, Sharing, Reporting und Automatisierung profitiert.
• Geschäftsprozesse abbildet, die bereits in Salesforce laufen.
• Eine Mischung aus deklarativen Seiten und eigenen Komponenten benötigt.
• CRM-gestützten Self-Service oder Zusammenarbeit erfordert.
• Zu den Governor Limits, Datenmengen, Antwortzeitanforderungen und Lizenzen für externe Benutzer von Salesforce passt.

Beispiele sind Kundenserviceportale, Deal-Registrierung für Partner, Garantieansprüche, Antragsannahme, Kurseinschreibung, Kontoverwaltung, Fallverfolgung, B2B-Bestellungen, Lieferanten-Onboarding und Unterstützung im Außendienst.

Wann ein hybrider Stack besser ist

Eine separate oder hybride Architektur kann besser sein, wenn die Anwendung Folgendes erfordert:

• Extrem hohen anonymen Traffic mit einem Kostenmodell, das nicht passt.
• Sehr große Produktkataloge mit fortgeschrittener Suche, Ranking und Merchandising.
• Transaktionen mit hohem Durchsatz, Zusammenarbeit mit niedriger Latenz oder Streaming-Lasten.
• Spezialisierte Rechenleistung oder direkte Kontrolle über die Runtime-Infrastruktur.
• Ungewöhnliche Datenbankzugriffsmuster oder große Datenmengen, die innerhalb der Plattformlimits schwer zu bedienen sind.
• Umfangreiche Analyse-Workloads, die eine dedizierte Datenplattform besser bewältigt.
• Gastzugriff, der sich nicht sicher in das Zugriffsmodell von Salesforce einfügen lässt.
• Komplexe systemübergreifende Orchestrierung, die in Middleware oder ein dediziertes Backend gehört.

Auch in diesen Fällen kann Experience Cloud eine Rolle spielen: als authentifiziertes Portal, Kundenkonto-Bereich, Oberfläche für Fallmanagement oder Ebene für Geschäftsworkflows, während eine andere Plattform Suche, Checkout, Streaming oder spezialisierte Verarbeitung übernimmt.

Praktische Strategie für Experience-Cloud-Projekte

Bevor Sie sich auf eine Experience-Cloud-Architektur festlegen, beantworten Sie diese Fragen:

1. Wer sind die Benutzer: Kunden, Partner, Gäste, Mitarbeitende oder eine Mischung?
2. Welche Daten müssen in Salesforce liegen, und welche sollten extern bleiben?
3. Welche Seiten kommen mit Standardkomponenten aus, und welche brauchen eigene LWC?
4. Welche Vorgänge erfordern Apex statt LDS oder UI API?
5. Was sollen Flow, Apex, asynchrone Verarbeitung, Agentforce oder Middleware übernehmen?
6. Wie sieht das Zugriffsmodell für Gastbenutzer aus?
7. Welche Mengen sind bei Benutzern, Datensätzen, Transaktionen, Dateien und API-Aufrufen zu erwarten?
8. Welche Lizenzen und Produkte werden benötigt?
9. Wie wird die Site bereitgestellt, getestet, veröffentlicht und überwacht?
10. Was würde Salesforce für einen Teil der Architektur zum falschen Verantwortlichen machen?

Halten Sie ein MVP schlank: Experience Builder für das Site-Gerüst, Standardkomponenten wo sie ausreichen, LWC für individuelle Interaktion, LDS oder UI API für den Standardzugriff auf Datensätze, Apex für das Verhalten der Serviceschicht, Flow für von Admins verantwortete Orchestrierung, Platform Events oder asynchrones Apex für Hintergrundaufgaben und Middleware, sobald die systemübergreifende Orchestrierung anspruchsvoll wird.

Härten Sie die Implementierung danach. Prüfen Sie Profile, Berechtigungssätze, Sharing, externe organisationsweite Standardeinstellungen und FLS. Testen Sie Gast- und authentifizierten Zugriff getrennt. Ergänzen Sie Apex-Tests für das Serviceverhalten. Prüfen Sie Abfrageselektivität und API-Limits. Dokumentieren Sie die Verantwortung für Integrationen und die Rollback-Schritte.

Häufig gestellte Fragen

Kann Experience Cloud einen individuellen Web-Stack ersetzen?

Für Geschäftsanwendungen mit Salesforce-Anbindung oft ja. Für spezialisierte Systeme im Consumer-Maßstab, Streaming, suchlastige oder infrastrukturintensive Systeme ist sie meist besser als Teil einer hybriden Architektur aufgehoben.

Brauchen alle individuellen Experience-Cloud-Seiten Apex?

Nein. Standardkomponenten, LDS und UI API decken viele datensatzorientierte Erlebnisse ab. Apex brauchen Sie für eigene Geschäftslogik, Aggregation, Orchestrierung oder Integration.

Ist Experience Cloud dasselbe wie Commerce Cloud?

Nein. Salesforce-Commerce-Storefronts, einschließlich B2B- und D2C-Commerce-Stores, können jedoch LWR und Funktionen von Experience Cloud nutzen. Commerce ist eine Produktfähigkeit, Experience Cloud kann die Ebene für das Storefront-Erlebnis sein.

Sollte jedes Experience-Cloud-Projekt Agentforce enthalten?

Nicht automatisch. Agentforce lohnt sich für Self-Service, geführten Support, Suche und personalisierte Unterstützung, muss aber mit Blick auf Identität, Berechtigungen, Datenzugriff, Tests und Lizenzierung konzipiert werden.

Fazit: Experience Cloud gezielt als Full-Stack-Plattform einsetzen

Experience Cloud kann für die richtige Art von Salesforce-gestützter Anwendung als verwaltete Full-Stack-Plattform dienen. Experience Builder liefert das Fundament der Site. LWC liefert die individuelle Frontend-Interaktion. Apex und Flow liefern Backend-Logik und Orchestrierung. Salesforce-Objekte liefern das Datenmodell. Identität, Berechtigungen, Sharing und FLS bilden das Fundament der Zugriffskontrolle. APIs, Callouts, Events, Commerce, Agentforce, Data 360 und Middleware verbinden das Erlebnis mit dem Rest des Unternehmens.

Die besten Architekturen nutzen Salesforce dort, wo Salesforce stark ist: sichere Geschäftsworkflows, CRM-gestützte Daten, Erlebnisse für externe Benutzer, Automatisierung, Self-Service und die Integration von Unternehmensprozessen. Externe Systeme kommen dort zum Einsatz, wo sie stärker sind.

Regel zum Mitnehmen

Legen Sie das Zugriffsmodell fest, bevor Sie die erste Seite bauen. Klären Sie, wer die externen Benutzer sind, welche Lizenz sie haben und was jedes Profil, jeder Berechtigungssatz, jede Sharing-Regel und jedes Feld ihnen zeigt. Bauen und testen Sie die Seiten gegen dieses Modell und nicht umgekehrt, und testen Sie Gast- und authentifizierte Benutzer getrennt. Das ist umso wichtiger, seit API 67.0 Datenbankoperationen standardmäßig im User Mode ausführt.

So unterstützt Incresco

Incresco unterstützt Teams dabei, zu entscheiden, ob Experience Cloud der gesamte Stack oder ein Teil eines hybriden Stacks sein sollte, und die Lösung anschließend zu konzipieren und umzusetzen: Architektur und Datenmodell, Zugriffs- und Sharing-Design, LWC, Apex, Integrationen, Agentforce, Deployment und Produktionsreife.

Ein guter erster Schritt ist ein Architektur- und Security-Review für Experience Cloud. Er prüft die Eignung für Ihren Anwendungsfall, das Identitäts- und Sharing-Modell, die Bereitschaft für API 67.0 und die Integrationslimits. Architektur- und Security-Review für Experience Cloud anfragen.