Eine Salesforce-Integration scheitert fast nie am Protokoll. Authentifizierung ist ein gelöstes Problem, und einen Datensatz zu schreiben ebenfalls. Was Projekte beendet, sind das tägliche Anfragekontingent und die Form des Datenmodells, beides meist etwa drei Wochen nach dem Go-live entdeckt, wenn der nächtliche Job Fehler zurückgibt und niemand sagen kann, warum es im Test funktioniert hat.

Das Muster ist berechenbar genug. Ein Entwickler baut gegen eine Developer-Edition-Org, alles läuft durch, der Kunde nimmt ab. Der Code trifft dann auf eine Produktions-Org, in der bereits ein Marketing-Connector, ein Warehouse-Extrakt und ein Apex-Trigger von 2019 stecken, und aus dem großzügig wirkenden Anfragebudget wird ein gemeinsamer Topf, aus dem andere längst schöpfen.

Dieser Artikel zieht die Überraschungen nach vorn: welche API Sie einsetzen sollten, wie das Kontingent berechnet wird, was passiert, wenn Ihr Schreibvorgang fremden Code auslöst, wie sich die Authentifizierung geändert hat, und welche Entscheidungen im Datenmodell teuer rückgängig zu machen sind.

Was entscheidet über den Erfolg einer Salesforce-Integration? Kontingent und Datenmodell, nicht das Protokoll. Das tägliche API-Anfragekontingent gilt org-weit und ergibt sich aus Edition und Lizenzzahl, sodass eine saubere Integration von einer schlecht gebauten in derselben Org ausgehungert werden kann. Planen Sie Batching ab der ersten Codezeile, einigen Sie sich auf External IDs und Upsert, bevor irgendetwas geschrieben wird, und rechnen Sie damit, dass jeder gesendete Datensatz fremden Apex-Code auslöst.

Was eine Salesforce-Integration richtig machen muss

Es sind vier Dinge, und sie wiegen nicht gleich schwer.

Das erste ist das Kontingent. Jeder synchrone Aufruf Ihres Codes wird aus einem einzigen org-weiten Tageskontingent bezahlt, das mit jedem anderen Verbraucher der Org geteilt wird.

Das zweite ist die Plattform darunter. Salesforce ist keine Datenbank mit HTTP-Schnittstelle. Es ist eine Anwendungsplattform, und Ihre Schreibvorgänge führen Trigger, Flows, Validierungsregeln, Dublettenregeln und Roll-up-Summen aus, die Administratoren konfiguriert haben, die nie von Ihrem Projekt gehört haben.

Das dritte ist das Datenmodell. Lead, Contact, Account und Opportunity sind nicht austauschbar, die Konvertierung zwischen ihnen läuft nur in eine Richtung und hat Nebenwirkungen, und eine falsche Wahl bedeutet eine Datenmigration statt einer Codeänderung.

Das vierte ist Identität: wie Ihr System und Salesforce sich einig werden, welcher Datensatz welcher ist. Wer das falsch macht, erzeugt Dubletten in Maschinengeschwindigkeit. Alles Weitere hier folgt aus einem dieser vier Punkte.

Die API-Landschaft, und welche Sie wirklich brauchen

Salesforce veröffentlicht eine große Familie von APIs. Der Salesforce-API-Index ist die maßgebliche Liste, und die Namen unten stammen von dort statt aus dem Gedächtnis.

REST API und SOAP API

Die REST API ist der Standard für alles Datensatzförmige: anlegen, lesen, aktualisieren, löschen, abfragen, beschreiben. Sie ist die richtige Wahl für ein Webformular, das einen Lead schreibt, für ein Portal, das die offenen Cases eines Kunden liest, und für jeden interaktiven Pfad mit geringem Volumen.

Die SOAP API erledigt dieselbe Arbeit über eine WSDL und überlebt, weil sehr viel Enterprise-Middleware sie nativ spricht und weil sie einen streng typisierten Vertrag liefert, aus dem sich ein Client generieren lässt. Der verbreitete Irrtum ist die Annahme, SOAP sei Legacy und REST modern. Beide sind aktuell, und SOAP create() und update() nehmen jeweils bis zu 200 Datensätze an, was mehr zählt als das Übertragungsformat.

Bulk API 2.0

Die Bulk API 2.0 ist der asynchrone, jobbasierte Weg für Volumen. Sie laden eine CSV hoch, Salesforce zerteilt und verarbeitet sie im Hintergrund, und Sie fragen die Ergebnisse ab. Die Limits der Bulk API erlauben bis zu 15.000 Batches pro rollierende 24 Stunden und bis zu 150 Millionen aufgenommene Datensätze im selben Fenster, bei einer Obergrenze von 150 MB je Job-Datei.

Der verbreitete Irrtum ist, Bulk als spätere Optimierung zu behandeln. Es ist ein anderes Programmiermodell: Ergebnisse kommen asynchron und pro Datensatz zurück, und Ihr Code muss sie von Anfang an so verarbeiten.

Composite und sObject Collections

Diese beiden sind der wertvollste und am wenigsten genutzte Teil der REST API. Eine Composite-Anfrage trägt bis zu 25 Unteranfragen in einem einzigen Aufruf, davon bis zu 5 Abfragen oder sObject-Collections-Operationen, und spätere Unteranfragen können IDs referenzieren, die frühere zurückgegeben haben. sObject Collections verarbeitet bis zu 200 Datensätze desselben Objekts in einer Anfrage. Beide zählen als ein einziger Aufruf gegen Ihr Tageskontingent, und genau darum geht es.

Der verbreitete Irrtum ist, sie gar nicht zu kennen. Einen Account, dann einen Contact, dann eine Opportunity als drei aufeinanderfolgende Aufrufe anzulegen kostet dreimal so viel Kontingent wie eine Composite-Anfrage, und dreimal so viel Latenz.

Streaming, Change Data Capture und Pub/Sub

Die Streaming API ist der CometD-basierte Abonnementkanal für PushTopic-, generische, Platform- und Change-Events. Change Data Capture veröffentlicht Benachrichtigungen nahezu in Echtzeit, wenn Datensätze angelegt, geändert, gelöscht oder wiederhergestellt werden, sodass ein externer Speicher Salesforce ohne Polling folgen kann. Platform Events sind Ihre eigenen Ereignisdefinitionen.

Die Pub/Sub API ist die neuere gRPC- und HTTP/2-Schnittstelle, die Veröffentlichen, Abonnieren, Schemaabruf und Topic-Discovery in einer API bündelt, mit Nutzlasten in Avro statt JSON. Für einen neuen ereignisgesteuerten Aufbau fangen Sie dort an.

Der verbreitete Irrtum ist, Ereignisse als garantierten Datenstrom zu behandeln. Sie ersetzen den Abgleich nicht, aus dem Grund im nächsten Abschnitt.

API-Anfragelimits sind die eigentliche Grenze

Das ist der Abschnitt, der Ihre Architektur entscheidet, und der am häufigsten erst gelesen wird, wenn der Entwurf fertig ist.

Wie das Tageskontingent berechnet wird

Die Dokumentation zu den API-Anfragelimits legt das Kontingent nach Edition und Lizenzzahl fest, nicht nach Benutzer oder Anwendung. Enterprise- und Professional-Editionen mit API-Zugriff erhalten 100.000 Aufrufe plus 1.000 je Salesforce- oder Salesforce-Platform-Lizenz. Unlimited- und Performance-Editionen erhalten 100.000 plus 5.000 je Lizenz. Die Developer Edition erhält pauschal 15.000, eine Full-Sandbox 5.000.000.

Zweierlei folgt daraus. Eine Enterprise-Org mit 60 Benutzern hat rund 160.000 Aufrufe pro Tag, keinen unbegrenzten Vorrat. Und weil sich das Kontingent aus Lizenzen ableitet, lässt es sich nur über weitere Benutzerlizenzen oder zusätzlich gekaufte API-Aufrufe erhöhen, beides über die Your-Account-App von Salesforce.

Was zählt, und was passiert, wenn nichts mehr da ist

Das Kontingent wird gegen die Summe aller Aufrufe an die Org in einem Zeitraum von 24 Stunden gemessen und umfasst REST API, SOAP API, Bulk API, Bulk API 2.0 und die meisten Aufrufe der Connect REST API zusammen. Aufrufe bestimmter verbundener Salesforce-Anwendungen, etwa der Mobile-App, sind ausgenommen.

Diese Summierung erwischt die Leute. Ihre Integration hat kein eigenes Budget. Sie teilt es mit dem Reporting-Connector, der Marketing-Plattform und jeder anderen Integration in der Org, und ein einziger schlecht gebauter Verbraucher, der alle dreißig Sekunden abfragt, kann es leeren und Code aushungern, der sich einwandfrei verhält.

Überschreitet die Org ihr Kontingent, schlagen Anfragen mit einem 403 und REQUEST_LIMIT_EXCEEDED fehl. Salesforce lässt bezahlten Produktions-Orgs eine gewisse Überschreitung durchgehen, bevor hart durchgegriffen wird, Test- und Developer-Edition-Orgs bekommen diese Gnade nicht. Planen Sie so, als gäbe es sie nicht.

Messen, bevor Sie sich auf einen Entwurf festlegen

Holen Sie sich Kontingent und aktuellen Tagesverbrauch der Org vom Administrator, bevor Sie Code schreiben; die REST API stellt dafür eine Ressource mit den Org-Limits bereit. Wenn bestehende Verbraucher bereits 70 Prozent nutzen, ist eine synchrone Integration pro Datensatz nicht tragfähig, und Tuning macht sie es auch nicht.

Batching ist eine Entwurfsentscheidung, keine Optimierung

Sobald Sie akzeptieren, dass Kontingent endlich und geteilt ist, ergibt sich der Entwurf von selbst.

Schleifen Sie nie einen Einzelsatz-Aufruf. Ein Job, der 5.000 Contacts einzeln anlegt, verbraucht 5.000 Aufrufe. Dieselben 5.000 über sObject Collections zu 200 pro Anfrage verbrauchen 25. Dieser Faktor 200 ist der Unterschied zwischen einer Integration, die in das Kontingent einer mittelgroßen Org passt, und einer, die es nicht tut.

Setzen Sie Composite ein, wo die Arbeit ein Graph statt einer Liste ist. Einen Elterndatensatz und seine Kinder in einer Anfrage anzulegen spart die Roundtrips und den Zwischenzustand, den Ihr Code sonst beim Warten auf eine ID halten müsste.

Setzen Sie die Bulk API 2.0 für alles ein, was einem Laden oder Exportieren ähnelt statt einer Transaktion. Für interaktive Pfade ist sie falsch, weil sie von Haus aus asynchron ist und dem Benutzer keine synchrone Antwort gibt.

Cachen Sie Referenzdaten. Picklist-Werte, Record-Type-IDs und Describe-Ergebnisse ändern sich selten und werden ohne Grund bei jedem Lauf neu geholt. Diese eine Änderung entfernt oft ein Viertel des Aufrufvolumens einer naiven Integration.

Governor Limits: Ihr Schreibvorgang führt fremden Code aus

Salesforce führt kundenseitig geschriebenen Apex innerhalb strenger Obergrenzen pro Transaktion aus. Die Apex Governor Limits, die für eine Integration zählen, sind 100 SOQL-Abfragen pro synchroner Transaktion, 50.000 per SOQL abgerufene Datensätze, 150 DML-Anweisungen, 10.000 per DML verarbeitete Datensätze, 10 Sekunden synchrone CPU-Zeit und 6 MB Heap.

Diesen Apex schreiben Sie nicht. Sie laufen trotzdem in diese Limits, weil Ihr eingehender Schreibvorgang eine Transaktion startet, die alle auf dem Objekt vorhandenen Trigger ausführt.

Bulkification, ohne Apex

Die Idee lohnt sich zu verstehen, auch wenn Sie nie eine Apex-Datei öffnen.

Salesforce übergibt einem Trigger eine Sammlung von Datensätzen, nicht einen einzelnen. Ein korrekt geschriebener Trigger verarbeitet die ganze Sammlung mit einer Abfrage und einer Aktualisierung. Ein Trigger, der so geschrieben ist, als bekäme er immer einen einzelnen Datensatz, führt eine Abfrage und eine Aktualisierung pro Datensatz aus.

Dieser zweite Trigger funktioniert jahrelang einwandfrei, weil Benutzer über die Oberfläche einzeln speichern. Dann sendet Ihre Integration 200 Datensätze in einer Anfrage, der Trigger führt seine Abfrage 200 Mal aus, sprengt die Grenze von 100 Abfragen, und der ganze Batch scheitert.

Die Bulk API 2.0 verarbeitet Ingest-Daten in Blöcken von 200 Datensätzen, jeder eine eigene Transaktion, das ist also nicht theoretisch. Es ist die übliche Form eines ersten Massenimports in eine Org mit Geschichte.

Was dagegen zu tun ist

Prüfen Sie die Trigger und Flows auf jedem Objekt, in das Sie schreiben werden, bevor Sie einen Liefertermin zusagen. Ist ein Trigger nicht bulkifiziert, muss ihn jemand reparieren, und dieser Jemand braucht Apex-Kenntnisse und ein Deployment-Fenster. Kalkulieren Sie das als eigene Position.

Wo eine Reparatur außerhalb des Auftrags liegt, verkleinern Sie die Batchgröße. Zweihundert pro Anfrage ist ein Maximum, keine Pflicht, und ein Absenken auf 50 verschafft manchmal genug Luft, um zu liefern, während die Trigger-Arbeit eingeplant wird. Es kostet Kontingent, behandeln Sie es also als Übergangslösung.

Authentifizierung, die auch nächstes Jahr noch funktioniert

Dieser Bereich hat sich deutlich verändert, und viele veröffentlichte Anleitungen sind inzwischen falsch.

Der OAuth 2.0 Flow mit Benutzername und Passwort ist der, den Sie meiden sollten. Er legt Zugangsdaten direkt in der Anfrage offen, Salesforce blockiert ihn in neueren Orgs standardmäßig, und seine Abschaltung für Connected Apps ist terminiert. Jede Integration, die ihn noch nutzt, braucht einen Migrationsplan mit Datum.

Für Server-zu-Server-Arbeit ohne Menschen in der Schleife sind die beiden aktuellen Antworten der JWT-Bearer-Flow, der eine Assertion mit einem Zertifikat signiert, und der Client-Credentials-Flow, der Consumer Key und Secret gegen ein Token tauscht. Die Salesforce-Anleitung zum Aufruf von REST-APIs mit dem Integrationsbenutzer und Client Credentials sagt ausdrücklich, dass dieser Flow kein Refresh-Token ausstellt, der Client fordert also ein neues Access-Token an, wenn das alte abläuft.

Connected Apps und External Client Apps

Der Container dafür war früher die Connected App. Jetzt ist es die External Client App. Salesforce stellt klar, dass die Erstellung von Connected Apps ab Spring ‘26 eingeschränkt ist, und empfiehlt stattdessen External Client Apps, beschrieben als die neue Generation, die Sicherheit verbessern und Paketierungsprobleme lösen soll.

Wenn Ihre Integrationsdokumentation sagt “Legen Sie eine Connected App an”, beschreibt sie einen Weg, den neue Orgs möglicherweise nicht anbieten. Prüfen Sie vor der Aufwandsschätzung, was für die Ziel-Org gilt.

Als eigener Integrationsbenutzer laufen und Rotation einplanen

Geben Sie der Integration einen eigenen Benutzer mit einem Profil, das nur API-Zugriff und minimale Rechte hat. Betreiben Sie sie nicht unter einem namentlichen Mitarbeiter. Wenn dieser Mitarbeiter geht und sein Konto deaktiviert wird, steht die Integration still, zum denkbar schlechtesten Zeitpunkt und mit einer Fehlermeldung, die nirgendwohin führt.

Zertifikate laufen ab und Secrets werden rotiert. Beides ist still bis zu dem Tag, an dem es das nicht mehr ist, und beides nimmt eine Integration vollständig statt teilweise vom Netz. Tragen Sie die Ablaufdaten in einen Kalender ein, der einer Person gehört, legen Sie Zugangsdaten in einem Secret-Manager ab, und testen Sie die Rotation in einer Sandbox, bevor Sie sie im Ernstfall brauchen.

Die Fallen im Datenmodell

Das sind die Dinge, die drei Wochen kosten, weil sie rückgängig zu machen bedeutet, Daten zu verschieben statt Code zu ändern.

Lead, Contact, Account und Person Account

Ein Lead ist ein unqualifizierter Interessent, der noch nicht mit einem Firmendatensatz verbunden ist. Ein Contact ist eine Person, die an einem Account hängt. Ein Account ist eine Organisation. Die Konvertierung macht aus einem Lead einen Account und einen Contact, wahlweise mit einer Opportunity, und der SOAP-Aufruf convertLead sagt ausdrücklich, dass nur leere Felder im Ziel überschrieben werden, Ihre sorgfältig befüllten Lead-Felder landen also womöglich nicht dort, wo Sie es erwarten.

Person Accounts verkomplizieren das. Business-to-Consumer-Orgs aktivieren sie, damit eine Einzelperson als kombinierter Account und Contact dargestellt wird, und eine Integration, die gegen ein geschäftliches Account-Modell geschrieben wurde, funktioniert ohne Änderung nicht gegen eine Org, die sie nutzt. Das wird mit ernüchternder Regelmäßigkeit spät entdeckt.

Entscheiden Sie mit dem Fachbereich, schriftlich, welches Objekt ein bestimmter eingehender Datensatz wird. Das ist keine technische Entscheidung.

External IDs und Upsert

Das ist der einzige vernünftige Idempotenzmechanismus, den Salesforce Ihnen gibt, und er sollte nicht verhandelbar sein. Legen Sie auf dem Objekt ein benutzerdefiniertes Feld an, das als External ID markiert ist, und speichern Sie darin den Primärschlüssel Ihres eigenen Systems. Sie können dann die Upsert-Operation nutzen, ein PATCH auf /sobjects/{Object}/{ExternalIdField}/{Value}, das den Datensatz anlegt, wenn nichts passt, und ihn aktualisiert, wenn genau eines passt. Null Treffer liefern 201, ein Treffer 200, und mehrere Treffer scheitern mit einem 300, statt zu raten.

Die Folge ist es wert, klar gesagt zu werden. Mit Upsert ist der erneute Versuch einer fehlgeschlagenen Anfrage sicher. Ohne ihn ist jede Wiederholung eine mögliche Dublette, und eine Netzwerkstörung während eines nächtlichen Jobs wird zu einer Aufräumarbeit, die in Tagen gemessen wird.

Regeln, die bei Ihren Schreibvorgängen feuern

Dublettenregeln können Datensätze blockieren oder melden, die Ihre Integration anlegt. Validierungsregeln weisen Datensätze ab, die Bedingungen verletzen, die ein Administrator konfiguriert hat. Pflichtfelder können Monate nach Ihrem Release hinzukommen, woraufhin eine funktionierende Integration bei jedem Datensatz zu scheitern beginnt.

Nichts davon ist ein Fehler; die Org arbeitet wie konfiguriert. Der Irrtum ist, einen abgewiesenen Schreibvorgang als Transportfehler zu behandeln und ewig zu wiederholen, wenn die richtige Antwort ist, ihn mit der feldgenauen Begründung an einen Menschen zu melden. Unser Leitfaden zu Fehlerbildern bei der Integration fremder APIs behandelt dieselbe Kategorie an anderer Stelle.

Fehlerbehandlung, Idempotenz und Wiedervorlage

Eine Integration ohne Wiedervorlagemechanismus wird zur manuellen Datenreparatur. Das ist keine Prognose, das ist der übliche Verlauf.

Teilerfolg ist der Normalfall. sObject Collections setzt allOrNone standardmäßig auf false, eine Anfrage mit 200 Datensätzen kann also 187 Erfolge und 13 Fehlschläge mit einzelnen Begründungen zurückgeben, und die Bulk API 2.0 liefert Ergebnisse pro Datensatz genauso. Code, der nur den äußeren HTTP-Status prüft, meldet Erfolg und verliert dabei stillschweigend Datensätze.

Klassifizieren Sie Fehler, bevor Sie wiederholen. Vorübergehende Zustände wie Zeilensperren, Zeitüberschreitungen und erschöpftes Kontingent verdienen exponentielles Zurückweichen. Deterministische Fehler wie Validierungsfehler und fehlende Pflichtfelder scheitern für immer gleich, und sie zu wiederholen verbrennt Kontingent, das Sie nicht übrig haben.

Jeder unrettbare Datensatz geht mit Nutzlast und Fehler in einen Dead-Letter-Speicher, damit ein Mensch ihn prüfen und erneut einreichen kann. Weil Ihre Schreibvorgänge auf eine External ID schlüsseln, ist das erneute Einreichen sicher. Protokollieren Sie die Zuordnung zwischen Ihrer Kennung und der Salesforce-ID auf beiden Seiten; in sechs Monaten ist dieses Protokoll das Einzige, was erklärt, warum der Datensatz eines Kunden falsch ist.

Und gleichen Sie ab. Platform- und Change-Events bleiben 72 Stunden im Event-Bus, und die Kontingente für Platform Events begrenzen die tägliche Zustellung auf 25.000 Ereignisse bei Enterprise und 50.000 bei Unlimited und Performance. Ein geplanter Vergleich von Datensatzzahlen und Änderungsdaten findet, was der Strom verloren hat.

Middleware oder direkt

Punkt zu Punkt ist häufiger richtig, als Plattformanbieter zugeben. Eine Quelle, ein Ziel, eine Richtung, moderates Volumen, ein stabiler Vertrag: bauen Sie es direkt und sparen Sie sich die Lizenz.

Middleware verdient ihre Kosten, wenn die Topologie aufhört, eine Linie zu sein. Mehrere Systeme, die Daten austauschen, Transformationen, die Fachanwender ohne Deployment ändern müssen, Orchestrierung über Systeme hinweg, die unabhängig ausfallen, ein echter Bedarf an zentralem Monitoring und zentraler Wiederholung.

Ehrlich anzumerken ist, dass Middleware die Kosten verschiebt, statt sie zu entfernen. Sie zahlen weiterhin für die Abbildung, die Fehlerbehandlung und das Betriebswissen, und Sie fügen eine Lizenz, eine zweite Pipeline und ein zweites Skillset zum Einstellen hinzu. Das API-Kontingent ändert sich nicht, weil Middleware dieselben APIs aufruft, die Ihr Code aufgerufen hätte.

Wählen Sie sie, weil Ihre Topologie sie braucht, nicht weil sie Code zu sparen scheint. Unser Leitfaden zur Make-or-Buy-Entscheidung arbeitet denselben Kompromiss für die zugrunde liegenden Systeme durch, und der Leitfaden zur CRM- und ERP-Integration behandelt den Fall mit mehreren Systemen. Wenn Sie das bewertet statt diskutiert haben möchten, beginnen dort unsere Projekte in der Softwareentwicklung.

Sandboxes, Deployment und API-Versionen

Bauen Sie in einer Sandbox. Nie gegen die Produktion, und nie gegen eine Developer-Edition-Org, die die Produktionskonfiguration nicht teilt, denn die Konfiguration ist es, die Sie brechen wird.

Verstehen Sie, was ein Refresh tut. Er ersetzt die Sandbox durch eine frische Kopie aus der Produktion, alle Testdaten, die nur dort existierten, sind also weg. Was einen Refresh überleben muss, muss skriptgesteuert und wiederholbar sein. Teams lernen das, indem sie eine Woche Testdaten verlieren.

Pinnen Sie Ihre API-Version ausdrücklich in jedem Anfragepfad und kennen Sie die Abkündigungsrichtlinie. Die Salesforce-Richtlinie zum API-Lebensende sagt zu, jede Version mindestens drei Jahre zu unterstützen und Kunden mindestens ein Jahr vor Supportende zu benachrichtigen. Die Versionen 21.0 bis 30.0 wurden in Summer ‘25 abgeschaltet, und Anfragen gegen eine abgeschaltete Version liefern 410 Gone.

Das ist ein harter Stopp, keine Verschlechterung, und darum gehört das Pinnen der Version in Ihren Wartungsplan. Dieselbe Disziplin gilt für jede API, die Sie selbst veröffentlichen, wie in unserem Beitrag zur API-Versionierung beschrieben.

Britischer Datenschutz und CRM-Daten

Ein CRM besteht fast vollständig aus personenbezogenen Daten: Namen, Arbeitgeber, Telefonnummern, E-Mail-Adressen, Notizen zu Gesprächen. Sie zwischen Systemen zu bewegen ist Verarbeitung nach der UK GDPR.

Die erste Frage ist, wer Verantwortlicher ist. Die Leitlinie der ICO zu Verantwortlichen und Auftragsverarbeitern definiert den Verantwortlichen als die Partei, die Zwecke und Mittel der Verarbeitung bestimmt, und den Auftragsverarbeiter als denjenigen, der im Auftrag des Verantwortlichen verarbeitet. Wenn eine Agentur eine Integration für Sie baut und betreibt, ist diese Agentur meist Auftragsverarbeiter, und ein schriftlicher Vertrag, der die Anforderungen aus Artikel 28 erfüllt, ist Pflicht statt Kür.

Die zweite ist die Übermittlung ins Ausland. Salesforce-Orgs und jede Middleware können außerhalb des Vereinigten Königreichs liegen, und die Leitlinie der ICO zu internationalen Übermittlungen beschreibt die verfügbaren Mechanismen und wann eine Risikobewertung nötig ist. Klären Sie vor der Unterschrift, wo die Daten landen.

Drei Konsequenzen folgen. Kopieren Sie keine Felder, die Sie nicht brauchen, denn Datenminimierung ist zugleich Rechtspflicht und weniger Abbildungsarbeit. Legen Sie keine echten personenbezogenen Daten ohne bewusste Entscheidung in eine Sandbox. Und sorgen Sie dafür, dass Löschungen durchgereicht werden, denn ein in Salesforce gelöschter und im Warehouse belassener Kontakt ist ein akutes Compliance-Problem, und dasselbe gilt, wenn KI-Agenten diese Datensätze erreichen.

Was eine Salesforce-Integration kostet

Salesforce veröffentlicht Edition- und Lizenzpreise auf den eigenen Preisseiten, und wir nennen hier keine Zahl dafür, weil die für den Integrationsentwurf maßgebliche Größe das API-Kontingent ist, das diese Lizenzen erzeugen, nicht der Listenpreis.

Die folgenden Zahlen sind Mecaniks eigene britische Schätzungen für Professional Services, keine Herstellerpreise, und setzen eine bereits bestehende Org mit einem Administrator voraus, der Fragen beantworten kann.

Eine einfache Einwegintegration, ein Webformular, das einen Lead mit External ID und vernünftiger Fehlerbehandlung anlegt, liegt typischerweise bei GBP 3.000 bis GBP 7.000. Eine bidirektionale Synchronisation von einem oder zwei Objekten mit Konfliktauflösung und einem Abgleichsjob kostet meist GBP 15.000 bis GBP 40.000. Eine ereignisgesteuerte Integration auf Pub/Sub mit Wiedervorlage, Dead-Letter-Behandlung und Monitoring landet in der Regel zwischen GBP 30.000 und GBP 80.000.

Was im Ergebnis enthalten sein sollte

Ein feldgenaues Mapping-Dokument, das mit dem Fachbereich abgestimmt und nicht erraten wurde. Eine External ID auf jedem synchronisierten Objekt. Fehlerbehandlung mit Dead-Letter-Speicher und dokumentiertem Wiedereinreichungsprozess. Ein Abgleichsjob. Monitoring des API-Verbrauchs gegen das Kontingent der Org, mit Alarmierung deutlich unterhalb der Grenze. Runbooks für Token-Rotation, Zertifikatsablauf und Wiedervorlage. Skriptgesteuerte Sandbox-Konfiguration, die einen Refresh übersteht. Eine Integration ohne das ist ein Prototyp, was auch immer auf der Rechnung steht.

Laufende Kosten

Planen Sie GBP 400 bis GBP 1.500 im Monat für Monitoring, drei Salesforce-Releases im Jahr, Rotation der Zugangsdaten und die Feldänderungen, die ein Administrator vornimmt, ohne es Ihnen zu sagen. Die Orgs, die das finanzieren, sind die Orgs, in denen Integrationen weiter funktionieren.

Wie es gebaut wird

Die Fehlerbilder hier sind langweilig gleichförmig: Kontingent zu spät entdeckt, ein Trigger, den niemand geprüft hat, ein Lead, der ein Contact hätte sein sollen, keine Möglichkeit, einen fehlgeschlagenen Batch zu wiederholen. Alle vier sind zur Entwurfszeit billig zu verhindern und teuer zu beheben, sobald echte Datensätze existieren.

Mecanik baut und betreut Salesforce-Integrationen als Teil unserer Arbeit in der Softwareentwicklung, beginnend mit einer Prüfung von Kontingent, Triggern und Datenmodell der Org, bevor eine Zeile Code geschrieben wird. Für ein abgegrenztes Stück Integrationsarbeit statt eines vollen Projekts können Sie direkt einen Webentwickler engagieren.

Häufig gestellte Fragen

Wie viele API-Aufrufe bekommt eine Salesforce-Integration pro Tag? Das hängt von Edition und Lizenzzahl ab, und das Kontingent gilt org-weit statt pro Integration. Enterprise- und Professional-Editionen mit API-Zugriff erhalten 100.000 Aufrufe plus 1.000 je Salesforce- oder Salesforce-Platform-Lizenz, Unlimited und Performance erhalten 100.000 plus 5.000 je Lizenz, und die Developer Edition erhält pauschal 15.000 in einem rollierenden Zeitraum von 24 Stunden.

Sollte ich für Salesforce die REST API oder die Bulk API nutzen? Nutzen Sie die REST API für interaktive, datensatzförmige Arbeit mit geringem Volumen und die Bulk API 2.0 für Ladevorgänge und Exporte, bei denen das Volumen hoch ist und eine asynchrone Antwort akzeptabel ist. Für alles dazwischen zählen sObject Collections mit 200 Datensätzen pro Anfrage und Composite mit 25 Unteranfragen pro Anfrage jeweils als ein einziger Aufruf gegen Ihr Kontingent und nehmen den meisten Druck heraus.

Welchen OAuth-Flow sollte eine Server-zu-Server-Integration mit Salesforce nutzen? Den JWT-Bearer-Flow oder den Client-Credentials-Flow, ausgeführt als eigener Integrationsbenutzer mit reinem API-Zugriff. Der Flow mit Benutzername und Passwort ist in neueren Orgs standardmäßig blockiert und zur Abschaltung vorgesehen, er sollte für neue Arbeit also nicht verwendet werden. Beachten Sie außerdem, dass die Erstellung von Connected Apps ab Spring ‘26 eingeschränkt ist und Salesforce nun External Client Apps empfiehlt.

Warum scheitert meine Salesforce-Integration nur bei großen Batches? Fast immer an einem Apex-Trigger, der nicht bulkifiziert wurde. Salesforce übergibt Triggern eine Sammlung von Datensätzen, und ein Trigger, der so geschrieben ist, als bekäme er einen Datensatz nach dem anderen, führt seine Abfragen einmal pro Datensatz aus und überschreitet die Grenze von 100 SOQL-Abfragen, wenn Ihr Batch eintrifft. Für Oberflächenbenutzer, die einzeln speichern, funktioniert er einwandfrei, und darum blieb er unentdeckt.

Brauche ich Middleware für die Integration mit Salesforce? Nicht für eine Integration mit einer Quelle, einem Ziel und einer Richtung bei moderatem Volumen, wo der direkte Bau billiger und einfacher ist. Middleware verdient ihre Kosten, sobald mehrere Systeme Daten austauschen, Fachanwender Zuordnungen ohne Deployment ändern müssen oder Sie zentrale Orchestrierung und Wiederholung brauchen. Sie verschiebt Kosten, statt sie zu entfernen, und sie erhöht Ihr API-Kontingent nicht.