Headless CRM: Salesforce als API-First-Engine.

Was "headless" wirklich bedeutet

Eine klassische Salesforce-Implementierung koppelt drei Dinge an einem Ort: das Datenmodell, die Business-Logik und die Benutzeroberfläche. Headless CRM trennt das Frontend ab. Salesforce bleibt System of Record und Regel-Engine, aber die Oberflächen, mit denen Ihre Kunden und Mitarbeiter arbeiten, leben woanders — eine React-Web-App, eine native Mobile-App, ein Kundenportal, ein Kiosk, sogar die UI eines anderen Produkts. Diese Frontends sprechen mit Salesforce ausschließlich über APIs.

Es ist dieselbe Idee, die die Commerce-Welt mit Headless Commerce übernommen hat: ein komponierbares Backend, viele entkoppelte Experiences. Das CRM wird zu einem Service, den jeder Kanal aufrufen kann — statt zu einem Ort, in den sich Menschen einloggen müssen.

Die Salesforce-Bausteine

Salesforce eignet sich dafür gut, weil es seine Engine über eine tiefe API-Oberfläche verfügbar macht. Eine Headless-Architektur stützt sich typischerweise auf eine Kombination aus:

• REST- & SOAP-APIs — CRUD auf Standard- und Custom-Objekten, das Arbeitspferd für die meisten Lese- und Schreibzugriffe.
• GraphQL API — weniger Round-Trips für Frontends, die geformte, verschachtelte Daten in einem einzigen Aufruf brauchen.
• Connect API — Experience-Daten auf höherer Ebene (Feeds, Communities, Commerce), ohne sie neu zu bauen.
• Apex REST & Invocable Services — eigene Endpunkte, die komplexe Business-Logik in einen sauberen Vertrag kapseln.
• Platform Events & Change Data Capture — Änderungen werden nach außen gepusht, damit Frontends und nachgelagerte Systeme synchron bleiben.
• Data Cloud — ein Echtzeit-Daten-Backbone, das Profile und Events kanalübergreifend vereinheitlicht und an jede Experience zurückspielt.
• MuleSoft / API-Gateway — eine vorgelagerte Integrations- und Governance-Schicht, wenn viele Consumer im Spiel sind.

Die Authentifizierung läuft in der Regel über OAuth 2.0 — Client-Credentials- oder JWT-Bearer-Flows für Server-zu-Server und der passende Grant für nutzernahe Apps. Salesforce bleibt die identitätsbewusste Policy-Grenze; das Frontend sieht nie mehr, als sein Scope erlaubt.

Wann Headless die richtige Wahl ist

Headless ist ein bewusster Trade-off, kein Standard. Es rechnet sich, wenn:

• Sie eine vollständig gebrandete, pixelgenau kontrollierte Experience brauchen, die die Standard-UI von Salesforce nicht liefern kann.
• Sie viele Kanäle bedienen — Web, Mobile, Partnerportale, den stationären Handel — aus einer einzigen Source of Truth.
• Sie hohen, öffentlichen Traffic erwarten und eine schnelle Edge-Schicht vor dem CRM wollen.
• Sie CRM-Funktionalität in ein anderes Produkt einbetten, statt Nutzer nach Salesforce zu schicken.
• Sie die Freiheit wollen, das Frontend unabhängig vom Release-Zyklus der Plattform weiterzuentwickeln.

Wann nicht

Für interne Vertriebs- und Serviceteams ist die Standard-Lightning-Experience plus Konfiguration schneller gebaut, günstiger im Betrieb und leichter zu warten. Headless bedeutet dort, Navigation, Listenansichten, Reporting und Sicherheits-UI nachzubauen, die Salesforce bereits kostenlos mitliefert. Wenn das einzige Ziel "uns gefällt die Optik nicht" lautet, ist das selten ein eigenes Frontend und eine dauerhaft zu betreibende API-Integration wert.

Die wirklich schwierigen Teile

Das Versprechen ist sauber; über Erfolg oder Scheitern entscheidet das Engineering. Die wiederkehrenden Herausforderungen:

• API-Limits & Performance — Sie müssen mit Caching, Bulkification und einem Read-Model für Governor- und Request-Limits designen, statt die Org bei jedem Seitenaufruf zu bombardieren.
• Eine Source of Truth — Logik muss in Salesforce bleiben und darf nicht stillschweigend im Frontend nachgebaut werden, wo sie aus dem Takt gerät.
• Auth & Security — Token-Lifecycle, Scope, Feldsicherheit und Audit müssen serverseitig durchgesetzt werden und dürfen nie dem Client überlassen bleiben.
• Caching & Aktualität — eine Edge-/Read-Schicht hält Experiences schnell, braucht aber eventgesteuerte Invalidierung, damit Nutzer keine veralteten Daten sehen.
• Observability — wenn UI und Engine getrennte Systeme sind, brauchen Sie Tracing über die Systemgrenze hinweg, um überhaupt debuggen zu können.

Wie wir es angehen

Wir behandeln Salesforce als Produkt mit einem Vertrag. Wir definieren zuerst die API-Oberfläche — die Objekte, Services und Events, die das Frontend nutzen darf —, kapseln Business-Logik in versionierten Apex-/GraphQL-Endpunkten, setzen eine Caching- und Integrationsschicht davor, wo die Last es rechtfertigt, und nutzen Data Cloud, wenn Profile und Events in Echtzeit vereinheitlicht werden müssen. Das Ergebnis: eine Source of Truth unter klarer Governance — mit so vielen entkoppelten, gebrandeten Experiences darüber, wie das Business braucht.