// stack · schnittstelle
Salesforce ist eine cloudbasierte CRM-Plattform — und in vielen Vertriebsorganisationen das System, in dem am Ende jeder Kontakt landet. Für siteway heißt das: Die Website ist keine Insel, sondern der erste Schritt einer Kette. Diese Seite beschreibt die zwei Wege von einem Formular ins CRM — REST-API und Web-to-Lead — und wie wir sie anbinden.
// definition
Salesforce ist eine cloudbasierte CRM-Plattform. Vertrieb, Service und Marketing arbeiten darin im Browser mit denselben Datensätzen — bekannt vor allem als Sales Cloud für den Vertrieb, Service Cloud für den Kundenservice und Marketing Cloud für Kampagnen. Genutzt wird das System vor allem dort, wo viele Kontakte über längere Zeiträume und mehrere Stufen begleitet werden: in größeren Vertriebsorganisationen, im B2B-Geschäft, in Konzernstrukturen mit mehreren Standorten.
Datenseitig ist Salesforce ein Baukasten aus Objekten. Die vier, um die es bei einer Website fast immer geht, heißen Lead für den noch unqualifizierten Erstkontakt, Contact für die Person, Account für das Unternehmen dahinter und Opportunity für den laufenden Verkaufsvorgang. Wird ein Lead im Vertrieb konvertiert, entstehen daraus Account, Contact und auf Wunsch eine Opportunity. Wer versteht, an welcher Stelle dieser Kette ein Website-Formular andockt, hat die halbe Schnittstelle schon geplant.
Für die Website zählt davon vor allem eines: Salesforce dokumentiert seine REST-API öffentlich, mit OAuth 2.0 als Zugang und /services/data/ als Basispfad. Daneben steht mit Web-to-Lead ein Salesforce-eigener Weg, ein Formular ohne Programmierung entgegenzunehmen. Beide Wege führen dieselben Daten in dasselbe CRM. Sie unterscheiden sich darin, wie viel die Website unterwegs erfährt und beeinflussen kann.
// praxis
serverseitig · kein lead verloren
Die erste Entscheidung fällt vor der ersten Zeile Code, und sie ist immer dieselbe: Das Formular gehört der Website, nicht dem CRM. Wir bauen es im Design und in der Sprache des Auftritts, mit eigener Validierung, eigener Fehlermeldung und eigener Bestätigungsseite — und schicken es an einen eigenen Endpunkt auf dem Server. Erst dieser Endpunkt spricht mit Salesforce. Der Besucher merkt davon nichts, und im Browser läuft dafür kein Fremdcode. Wie ein solches Formular aufgebaut ist, beschreiben wir in der Leistung Formularstrecken.
Danach kommt der Zugang. In Salesforce wird eine App angelegt — je nach Ausbaustufe eine Connected App oder eine External Client App —, die den Zugriff erlaubt und die Rechte festlegt. Für die Verbindung von Server zu Server nutzen wir einen der beiden dokumentierten Wege ohne Nutzerinteraktion: den JWT-Bearer-Flow mit zertifikatssigniertem Token oder den Client-Credentials-Flow mit Consumer Key und Secret. Das Access Token ist kurzlebig; die Erneuerung übernimmt der Server im Hintergrund, gecacht und gemeinsam für alle Aufrufe, statt bei jedem Formular neu.
Dann das Feld-Mapping. Ein Lead in Salesforce hat sehr viele Felder, ein gutes Website-Formular sehr wenige. Wir legen fest, welches Formularfeld auf welches CRM-Feld geht, was Pflicht ist, was optional bleibt und welches Feld die Herkunft trägt — Kampagne, Seite, Sprachversion —, damit im Vertrieb später sichtbar ist, woher ein Kontakt kam. Alles, was nicht zugeordnet ist, wird gar nicht erst erhoben. Das ist Datensparsamkeit, und nebenbei ist es der kürzeste Weg zu einer höheren Absendequote.
Beim Schreiben gehen wir nicht blind auf „anlegen“. Über die Upsert-Ressource wird ein Datensatz über ein externes Schlüsselfeld angesprochen: Existiert er, wird er aktualisiert; existiert er nicht, wird er angelegt. Damit ist derselbe Aufruf zweimal harmlos — die Voraussetzung dafür, dass ein zweiter Versuch nach einer Störung keinen zweiten Lead erzeugt. Was Salesforce darüber hinaus an eigenen Dubletten- und Zuordnungsregeln mitbringt, bleibt dabei aktiv und macht die zweite Sicherung.
Und schließlich das, was in Angeboten gern fehlt: der Fehlerfall. Antwortet Salesforce nicht oder mit einem Fehler, wird der Vorgang nicht verworfen, sondern in eine Warteschlange gelegt und mit wachsendem Abstand erneut versucht. Jeder Versuch wird protokolliert, der Besucher bekommt seine Bestätigung trotzdem sofort, und der Lead geht zusätzlich per E-Mail raus. Ein Aussetzer im CRM darf nie zu einem verlorenen Kontakt werden — Details dazu in der Leistung Schnittstellenentwicklung.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus der öffentlichen Dokumentation von Salesforce — Ressourcen, Flows und Kopfzeilen im Original. Die Versionsnummer der API steht immer im Pfad, deshalb schreiben wir sie hier als vXX.X: Welche Version ein Projekt nutzt, wird beim Bauen festgelegt und nicht dem Zufall überlassen.
// d-01zugang
Der Zugriff läuft über OAuth 2.0 und eine in Salesforce angelegte App — Connected App oder External Client App. Für Server zu Server ohne Login dokumentiert Salesforce den JWT-Bearer-Flow, bei dem ein per Zertifikat nach RSA SHA256 signiertes JWT gegen ein Access Token getauscht wird, sowie den Client-Credentials-Flow mit Consumer Key und Secret und einem festgelegten Integrationsnutzer.
zweck: authentifizierung
// d-02objekte
Datensätze liegen unter /services/data/vXX.X/sobjects/{Objekt}/. Ein POST auf diese Ressource legt einen Datensatz an; die Antwort enthält die ID, ein Feld für Fehler und ein Erfolgskennzeichen. Für die Website relevant sind vor allem Lead, Contact, Account und Opportunity — welches Objekt ein Formular bedient, klärt das Mapping.
zweck: datensatz anlegen
// d-03dubletten
Ein PATCH auf /services/data/vXX.X/sobjects/{Objekt}/{Schlüsselfeld}/{Wert} legt den Datensatz an oder aktualisiert ihn — die Antwort sagt über ein Kennzeichen, welcher Fall eingetreten ist. Passen mehrere Datensätze auf den Schlüssel, kommt ein Fehler statt einer Vermutung zurück. Daneben greifen die Duplicate Rules und Matching Rules von Salesforce.
zweck: eindeutig schreiben
// d-04limits
Salesforce rechnet Aufrufe organisationsweit ab: gegen die Summe aller API-Aufrufe einer Organisation in 24 Stunden, über REST-API, SOAP-API, Bulk API und die meisten Connect-REST-APIs hinweg. Der Stand steht im Antwort-Header Sforce-Limit-Info und unter /services/data/vXX.X/limits/ im Wert DailyApiRequests. Die Website darf davon nur einen kleinen Teil brauchen.
zweck: geteilte ressource
// d-05web-to-lead
Der Salesforce-eigene Weg ohne Programmierung: Im Setup wird ein HTML-Formular erzeugt, das seine Daten an Salesforce schickt und danach auf eine selbst gewählte Seite weiterleitet. Wählbar sind Standard- und eigene Lead-Felder, dazu Kampagne, Datensatztyp und ein reCAPTCHA-Feld. Salesforce nennt ein Kontingent von bis zu 500 Leads in 24 Stunden; darüber hinausgehende Anfragen kommen in eine Warteschlange.
zweck: formular ohne code
// d-06zustellung
Kein Formular wartet auf das CRM. Der Eingang wird bestätigt, sobald die Daten auf dem Server liegen; die Übergabe an Salesforce läuft dahinter. Scheitert sie, wird der Vorgang mit wachsendem Abstand wiederholt, jeder Versuch protokolliert. Weil über den externen Schlüssel geschrieben wird, bleibt auch der dritte Versuch derselbe Datensatz.
zweck: kein lead verloren
Beide Wege sind von Salesforce vorgesehen, und beide führen ans Ziel. Sie beantworten nur unterschiedliche Fragen. Web-to-Lead ist ein Formular-POST mit anschließender Weiterleitung: schnell eingerichtet, ohne Programmierung, im Setup mit Zuordnungsregeln und Auto-Antwort kombinierbar. Es passt, wenn ein überschaubares Kontaktformular gebraucht wird, die Standardfelder reichen und das Tagesvolumen im dokumentierten Rahmen liegt.
Die REST-API passt, wenn die Website mehr wissen und mehr können soll: Sie bekommt eine strukturierte Antwort mit der ID des angelegten Datensatzes, kann vorher validieren, Felder gezielt zuordnen, mehrstufige Strecken abbilden, auf Fehler reagieren und die Übergabe wiederholen. Genau das braucht eine Lead-Magnet-Strecke mit Download, Double-Opt-in und Herkunftsdaten — und jede Anbindung, die neben Leads auch Kontakte oder Vorgänge berührt.
Häufig ist die ehrlichste Antwort eine Kombination: Web-to-Lead für das einfache Kontaktformular, die API für die Strecken, an denen Umsatz hängt. Welche Variante ein Projekt bekommt, klären wir im Konzept — vor dem Bauen, mit Begründung und mit dem Mapping als Dokument.
// integration
drei systeme · ein muster
Die Salesforce-Anbindung bauen wir in jedem System selbst — mit den Bordmitteln, die das CMS dafür mitbringt. Die Kette ist überall dieselbe, und sie hat eine klare Trennlinie. Im CMS liegt, was die Redaktion sieht und pflegt: das Formular als Inhalt oder Baustein, seine Felder und Beschriftungen, die Texte für Fehlermeldung und Bestätigung, die Zielseite nach dem Absenden, dazu die Zuordnung, welches Formular auf welches Salesforce-Objekt schreibt. Serverseitig läuft, was der Besucher nie zu sehen bekommt: die Anmeldung per OAuth, das gecachte Access Token und seine Erneuerung, die Prüfung der Eingaben, der Aufruf der API, die Warteschlange für gescheiterte Übergaben und das Protokoll. Die Zugangsdaten liegen dabei nie im Repository und nie im Frontend, sondern in der Konfiguration der jeweiligen Umgebung.
Weil die Website nichts aus Salesforce anzeigen muss, um Leads zu übergeben, bleibt sie in ihrer Geschwindigkeit unabhängig: Ausgeliefert wird aus Cache oder statisch erzeugten Seiten, das CRM wird erst beim Absenden angesprochen. Muss doch einmal etwas aus dem CRM auf die Seite — eine Liste, ein Status im Kundenbereich —, holen wir es gebündelt in einem Hintergrundlauf und halten es im eigenen Bestand, statt pro Seitenaufruf zu fragen. Das schont das organisationsweite Kontingent und macht die Website unabhängig davon, ob Salesforce gerade antwortet. Welches CMS darunter arbeitet, ändert an dieser Mechanik nichts — nur daran, wo der Code liegt und wie die Redaktion ihn bedient.
// cms-01typo3
TYPO3 bringt mit Extbase, TCA, dem Scheduler und Fluid alles mit, was eine Anbindung braucht. Wir bauen sie als eigene Extension: Das TCA beschreibt das Datenmodell, also die Formularfelder und ihre Zuordnung auf die Salesforce-Objekte. Das Absenden läuft über eine serverseitige Route mit eigener Middleware — dort werden die Eingaben geprüft, das Access Token geholt und der Aufruf an Salesforce abgesetzt. Gescheiterte Übergaben nimmt ein Scheduler-Task noch einmal auf, damit kein Vorgang liegen bleibt. Die Zugangsdaten stehen in der Konfiguration der Extension und nie im Template. Gerendert wird über Fluid, sodass Formular, Fehlermeldung und Bestätigung im Layout der Website liegen; die Redaktion platziert das Formular als Content-Element auf jeder Seite.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so überlebt sie jeden Theme-Wechsel und jedes Redesign. Eine eigene REST-Route nimmt das Formular entgegen, prüft die Eingaben serverseitig und übergibt sie an Salesforce; die Schlüssel liegen in der wp-config.php oder in einer Umgebungsvariablen, nicht in der Datenbank und nicht im Frontend. Ein geplanter Lauf im Hintergrund arbeitet die Warteschlange ab, wenn eine Übergabe nicht durchgegangen ist. Fürs Frontend kommen Template-Dateien und eigene Blocks für den Editor dazu, damit die Redaktion Formular, Bestätigungstext und Zielseite dort setzt, wo sie hingehören.
// cms-03statamic
Statamic läuft auf Laravel — und für eine API-Anbindung ist das der bequemste Unterbau der drei. Eine Route plus Controller nimmt das Formular entgegen, die Validierung kommt aus dem Framework, der Aufruf an Salesforce läuft als Job in der Queue, sodass der Besucher nicht auf das CRM wartet. Ein Artisan-Command im Laravel-Scheduler nimmt gescheiterte Übergaben erneut auf. Ein Blueprint beschreibt Formularfelder und Zuordnung im Control Panel, die Schlüssel stehen in der .env, Antlers oder Blade rendern Formular, Fehlermeldung und Bestätigung, Static Caching liefert die Seiten drumherum aus.
// datenschutz
datensparsam · serverseitig
Ein CRM verarbeitet personenbezogene Daten — Name, E-Mail-Adresse, Telefon, Unternehmen, dazu oft Notizen und Verlauf. Damit ist die Anbindung keine reine Technikfrage. Es braucht eine Rechtsgrundlage für die Verarbeitung, eine Datenschutzerklärung, die das Formular und den Empfänger benennt, und einen Vertrag zur Auftragsverarbeitung mit dem Anbieter der Plattform — genauso wie beim Hoster. Wer die Daten außerhalb der EU verarbeitet, braucht zusätzlich eine tragfähige Grundlage für die Übermittlung.
Technisch hat das drei Konsequenzen, die wir in jedem Projekt gleich behandeln. Erstens: kein Fremdcode im Browser des Besuchers. Das Formular gehört der Website, die Übergabe läuft serverseitig über TLS. So verlässt kein Datensatz die Seite, bevor der Besucher abgeschickt hat, und die Zugangsdaten bleiben da, wo sie hingehören. Zweitens: Datensparsamkeit als Voreinstellung. Übertragen wird, was im Mapping steht — nicht das, was ein Formular technisch abgreifen könnte. Kein Tracking-Profil im versteckten Feld, keine IP-Adresse ohne Zweck, kein Freitext für Daten, die niemand braucht.
Drittens: Einwilligung sauber und nachweisbar. Wo eine Einwilligung nötig ist — etwa für einen Newsletter neben der eigentlichen Anfrage —, steht sie als eigene Auswahl im Formular, unvorbelegt und getrennt vom Absenden. Was der Besucher zugestimmt hat, wird mit Zeitpunkt und Textstand protokolliert und wandert als Feld mit ins CRM, damit der Nachweis dort liegt, wo später damit gearbeitet wird. Dazu gehören Löschfristen und die Frage, wer im Vertrieb welche Felder überhaupt sehen darf. Wie wir das im Stack grundsätzlich handhaben, steht unter Sicherheit & Datenschutz.
// faq
Salesforce ist eine cloudbasierte CRM-Plattform. Vertrieb, Service und Marketing arbeiten darin im Browser mit denselben Datensätzen — bekannt sind vor allem Sales Cloud für den Vertrieb, Service Cloud für den Kundenservice und Marketing Cloud für Kampagnen. Genutzt wird das System vor allem von größeren Vertriebsorganisationen, die viele Kontakte über längere Zeiträume und mehrere Stufen begleiten. Für die Website zählt davon vor allem eines: Salesforce dokumentiert seine REST-API öffentlich und bietet daneben mit Web-to-Lead einen eigenen Weg, um Formulardaten als Lead entgegenzunehmen.
Über zwei Wege, die Salesforce selbst vorsieht. Der eine ist die REST-API: Ein eigener Endpunkt auf dem Server der Website nimmt das Formular entgegen, meldet sich per OAuth an und legt den Datensatz über die sObject-Ressource an, also mit einem POST auf /services/data/vXX.X/sobjects/Lead/. Die Antwort enthält die ID des angelegten Datensatzes, ein Feld für Fehler und ein Erfolgskennzeichen. Der andere ist Web-to-Lead: Salesforce erzeugt im Setup ein HTML-Formular, das seine Daten direkt an Salesforce schickt und den Besucher danach auf eine Seite weiterleitet, die du selbst festlegst. Welcher Weg trägt, entscheiden wir im Konzept — nach Aufgabe, nicht nach Modernität.
Es sind zwei Bauarten für dieselbe Aufgabe. Web-to-Lead ist ein Formular-POST an Salesforce mit anschließender Weiterleitung auf eine Zielseite. Es ist ohne Programmierung eingerichtet, lässt sich im Setup mit Zuordnungsregeln, Auto-Antwort-Vorlagen und einem reCAPTCHA-Feld kombinieren, und Salesforce nennt dafür ein Kontingent von bis zu 500 Leads in 24 Stunden; was darüber hinausgeht, landet in einer Warteschlange und wird nachgereicht. Über die REST-API bekommt die Website dagegen eine strukturierte Antwort zurück: Sie sieht, ob der Datensatz angelegt wurde, kennt seine ID, kann vorher validieren, Felder gezielt zuordnen und im Fehlerfall gezielt reagieren. Wer ein schlankes Kontaktformular braucht, ist mit Web-to-Lead schnell am Ziel. Wer Bestätigung, Zuordnung und Fehlerbehandlung im eigenen Ablauf haben will, nimmt die API.
Über OAuth 2.0. Dafür wird in Salesforce eine App angelegt — je nach Ausbaustufe eine Connected App oder eine External Client App —, die den Zugriff erlaubt und die Rechte festlegt. Für die Verbindung von Server zu Server, bei der niemand interaktiv einen Login bestätigen kann, dokumentiert Salesforce zwei Wege. Beim JWT-Bearer-Flow schickt der Server ein JWT an den Token-Endpunkt, signiert mit einem Zertifikat nach RSA SHA256, und bekommt dafür ein Access Token; die App muss vorher freigegeben sein, Scopes lassen sich im JWT nicht mitgeben. Beim Client-Credentials-Flow werden Consumer Key und Consumer Secret gegen ein Token getauscht, wobei ein festgelegter Integrationsnutzer die Verarbeitung trägt. Beides läuft ohne Nutzerinteraktion — und beides gehört auf den Server, nie in den Browser des Besuchers.
Salesforce rechnet API-Aufrufe nicht pro Formular ab, sondern organisationsweit. Die Dokumentation beschreibt ein Kontingent, das gegen die Summe aller API-Aufrufe einer Organisation in einem Zeitraum von 24 Stunden gerechnet wird; dazu zählen unter anderem die REST-API, die SOAP-API, die Bulk API und die meisten Connect-REST-APIs. Die Website teilt sich dieses Kontingent also mit jedem anderen System, das an derselben Salesforce-Organisation hängt. Deshalb fragt bei uns keine Seite das CRM bei jedem Aufruf. Wir bündeln Anfragen serverseitig, halten Daten im eigenen Bestand vor und schreiben nur, was geschrieben werden muss. Wie viel vom Kontingent übrig ist, meldet Salesforce im Antwort-Header Sforce-Limit-Info und über die Ressource /services/data/vXX.X/limits/ im Wert DailyApiRequests.
An zwei Stellen. Salesforce selbst bringt Dubletten- und Zuordnungsregeln mit, die sogenannten Duplicate Rules und Matching Rules; für Leads, Kontakte und Geschäftskunden sind Standardregeln von Haus aus aktiv und greifen beim Anlegen. Und die Website kann von sich aus eindeutig schreiben: Über die Upsert-Ressource wird ein Datensatz nicht blind angelegt, sondern über ein externes Schlüsselfeld angesprochen. Ein PATCH auf /services/data/vXX.X/sobjects/Lead/Schluesselfeld/Wert legt den Datensatz an, wenn es ihn noch nicht gibt, und aktualisiert ihn, wenn es ihn schon gibt; die Antwort sagt über ein Kennzeichen, welcher der beiden Fälle eingetreten ist. Passen mehrere Datensätze auf denselben Schlüssel, antwortet Salesforce mit einem Fehler, statt zu raten.
Dann darf der Lead trotzdem nicht verloren gehen. Der serverseitige Endpunkt nimmt das Formular entgegen und bestätigt dem Besucher den Eingang, sobald die Daten sicher liegen — nicht erst, wenn das CRM geantwortet hat. Bleibt die Antwort aus oder kommt ein Fehler zurück, wandert der Vorgang in eine Warteschlange und wird mit wachsendem Abstand erneut versucht. Jeder Versuch wird protokolliert. Und weil über die Upsert-Ressource mit einem eigenen Schlüssel geschrieben wird, entsteht auch beim dritten Anlauf kein dritter Datensatz. Zusätzlich geht der Lead per E-Mail an ein Postfach, damit jemand ihn auch dann sieht, wenn die Technik noch arbeitet. Ein Aussetzer wird so zur Verzögerung statt zum Datenverlust.
Ja, in allen dreien. Die Anbindung bauen wir in jedem System selbst, mit dessen eigenen Bordmitteln. In TYPO3 entsteht eine eigene Extension: Extbase als Unterbau, TCA für das Datenmodell, eine serverseitige Route mit Middleware für den Formularversand, ein Scheduler-Task für wiederholte Läufe, Fluid für das Frontend; die Zugangsdaten liegen in der Konfiguration der Extension. In WordPress entsteht ein eigenes Plugin statt Theme-Code, damit die Anbindung einen Theme-Wechsel überlebt: eine eigene REST-Route nimmt das Formular entgegen, die Schlüssel liegen in der wp-config.php oder in einer Umgebungsvariablen, Template-Dateien und Blocks bringen Formular und Bestätigung ins Frontend. In Statamic liegt Laravel darunter: Route plus Controller für den Versand, ein Artisan-Command im Scheduler für Wiederholungen, ein Blueprint als Datenmodell, die Schlüssel in der .env, Antlers oder Blade für die Ausgabe. In allen drei Fällen liegt der Zugang auf dem Server — im Browser des Besuchers läuft dafür kein Fremdcode.
// womit das zusammenhängt
systeme, formulare & leistung
// stack · schnittstelle
Das CRM mit starkem Marketing-Teil — anderes Modell, dieselbe Frage: Welche Felder gehen von der Website ins System und welche nicht?
zur technik →
// stack · schnittstelle
Das schlanke Vertriebs-CRM für kleinere Teams und wie ein Website-Formular seine Deals und Personen befüllt.
zur technik →
// stack · schnittstelle
Wenn hinter der Website nicht nur ein CRM steht, sondern das ERP: Stammdaten, Preise und Vorgänge aus dem Kernsystem.
zur technik →
// stack · grundlage
Wo Kontaktdaten fließen, wird es ernst: Zugangsdaten serverseitig, TLS, Datensparsamkeit, Auftragsverarbeitung.
zur technik →
// leistung · komponente
Das Formular als eigene Disziplin: Schritte, Validierung, Fehlermeldungen und die Bestätigung, die wirklich ankommt.
zur leistung →
// leistung · buchen
Die Technik hier, das Angebot dort: Analyse, Mapping, Umsetzung, Monitoring und Betrieb der Anbindung. Hier wird gebucht.
zur leistung →
// Leads von deiner Website direkt nach Salesforce?
Projekt anfragen