Sechs Muster, mit denen Architekt:innen Ausfälle bei Salesforce-Integrationen verhindern

Passen Sie das Muster zur Last an, wählen Sie bei hohem Volumen oder engen Abhängigkeiten standardmässig asynchrone und ereignisgesteuerte Ansätze, sichern Sie die Identität mit Named Credentials und eng gefassten OAuth-Berechtigungen, und überlassen Sie Orchestrierung, Wiederholungen und Transformation der Middleware statt zusammengeflicktem Apex-Code. Platform Events, Change Data Capture und Data Cloud decken die meisten entkoppelten Szenarien mit hohem Volumen ab, während Named Credentials und moderne OAuth-Abläufe jede Verbindung nachvollziehbar halten. Führen Sie vor dem nächsten Integrationsstart eine fünfminütige Musterprüfung am aktuellen Entwurf durch. Dabei zeigt sich fast immer mindestens eine Stelle, an der ein synchroner Aufruf klammheimlich eine Aufgabe erledigt, die eigentlich ein Ereignis übernehmen sollte.

---

Kurz gefasst:

• Nutzen Sie ereignisgesteuerte Muster wie Platform Events oder Change Data Capture für entkoppelte Szenarien mit hohem Volumen, um synchrone Aufrufe zu reduzieren und die Skalierbarkeit zu verbessern.

• Führen Sie vor der Umsetzung eine fünfminütige Musterprüfung durch, um synchrone Aufrufe zu erkennen, die durch ereignisbasierte Integrationen ersetzt werden sollten, besonders bei hoher Last.

• Wählen Sie standardmässig asynchrone Integrationsverfahren, ausser die Nutzerin oder der Nutzer wartet aktiv auf eine sofortige Rückmeldung. So vermeiden Sie Probleme mit Governor Limits und Sperrfehler auf Datensätzen.

• Setzen Sie bei veränderlichen externen Daten, die nicht in Salesforce gespeichert werden müssen, auf Datenvirtualisierung über Salesforce Connect. Replizieren Sie hingegen Daten, die häufig in Berichten und Flows gebraucht werden.

• Setzen Sie umfassende Sicherheitspraktiken um: Zugangsdaten in Named Credentials ablegen, OAuth-Berechtigungen minimal halten, Tokens regelmässig erneuern und Remote Site Settings auf vertrauenswürdige Domains beschränken.

Inhaltsverzeichnis

• Was sind die zentralen Salesforce-Integrationsmuster?

• Wie wählen Sie das richtige Integrationsmuster?

• Synchron oder asynchron integrieren?

• Replikation oder Virtualisierung: Welche Datenstrategie gewinnt?

• Welche Sicherheitsmassnahmen braucht jede Integration?

• Wie bauen Sie robuste und beobachtbare Integrationen?

• Wann sollten Sie Middleware statt nativer Salesforce-Werkzeuge einsetzen?

• Was gehört auf die Integrations-Checkliste einer Architektin oder eines Architekten?

• Unsere Sicht darauf, wo Integrationsprojekte wirklich scheitern

• Wie Ampersand Labs Salesforce-Integrationsprojekte unterstützt

• Quellen

• FAQ

Was sind die zentralen Salesforce-Integrationsmuster?

Die Salesforce-Integrationsarchitektur gliedert sich in drei Kategorien: Prozess, Daten und virtuell. Jede löst ein anderes Problem, und die falsche Wahl ist mit Abstand die häufigste Ursache für fragile Integrationen, die unter Last zusammenbrechen.

Prozessintegration verbindet Geschäftsprozesse über Systeme hinweg, meist um einen Ablauf nahezu in Echtzeit am Laufen zu halten. Datenintegration kopiert oder synchronisiert Datensätze zwischen Systemen, damit jedes seine eigene konsistente Kopie hat. Virtuelle Integration verzichtet ganz aufs Kopieren und fragt stattdessen das Quellsystem bei Bedarf ab. Die Architekturdokumentation von Salesforce beschreibt diese three-way split and a selection matrix, die jede Kategorie bestimmten Mustern zuordnet. Es lohnt sich, sie während jeder Design-Session offen zu halten.

Innerhalb dieser drei Kategorien decken sechs Muster fast alles ab, was Sie bauen werden:

• Request and Reply: ein synchroner Aufruf, bei dem die aufrufende Seite blockiert, bis eine Antwort eintrifft, typischerweise über REST oder SOAP. Am besten geeignet für Abfragen im Nutzerkontext, die in unter einer Sekunde eine Antwort brauchen, etwa eine Bonitätsprüfung beim Checkout. Fehlerbild: Zeitüberschreitungen schlagen bis zur Nutzerin durch, wenn das nachgelagerte System langsam ist.

• Fire and Forget: die aufrufende Seite schickt eine Nachricht und macht weiter, ohne auf eine Bestätigung zu warten. Gut für Protokollierung, Benachrichtigungen oder alles, wo das Ergebnis nicht sofort bekannt sein muss. Fehlerbild: Nachrichten gehen unbemerkt verloren, wenn es keine Bestätigung und keine Wiederholungsschicht gibt.

• Batch Data Sync: grosse Datenmengen wandern nach Zeitplan, meist nachts, über die Bulk API. Passend für den Abgleich mit einem Data Warehouse oder für Altsysteme, bei denen keine Echtzeitnähe nötig ist. Fehlerbild: teilweise fehlgeschlagene Stapel lassen zwei Systeme bis zum nächsten Lauf auseinanderlaufen.

• Remote Call-In: ein externes System ruft Salesforce auf, oft über die REST API oder Apex-REST-Endpunkte, um Datensätze zu lesen oder zu schreiben. Üblich bei mobilen Apps oder Partnerportalen. Fehlerbild: Governor Limits werden gerissen, wenn externe Systeme die Obergrenzen pro Transaktion in Salesforce nicht beachten.

• Datenvirtualisierung: Salesforce fragt die Daten eines externen Systems bei Bedarf ab, statt eine Kopie zu speichern, typischerweise über Salesforce Connect und OData oder eigene Adapter. Passt, wenn Daten sich zu häufig ändern, um sie repliziert zu halten, oder wenn Speicherkosten und Duplikate ein Thema sind. Fehlerbild: das gesamte Nutzungserlebnis leidet, sobald die Antwortzeit des externen Systems nachlässt.

• Publish and Subscribe: ein Ereignis wird einmal veröffentlicht, und beliebig viele Abonnenten greifen es auf, über Platform Events, Change Data Capture oder die Pub/Sub API. Das ist das Muster für Benachrichtigungen an viele Empfänger, etwa wenn fünf nachgelagerte Systeme im Moment des Abschlusses einer Opportunity informiert werden sollen. Fehlerbild: Abonnenten fallen hinter das Aufbewahrungsfenster der Ereignisse zurück und verpassen Nachrichten endgültig.

Die Salesforce blog’s own guidance on aligning patterns to use cases bringt einen Punkt, den man wiederholen darf: Ereignisgesteuerte Ansätze blockieren die aufrufende Seite nicht und kommen mit Parallelität deutlich besser zurecht als synchrone Aufrufe, sobald das Volumen steigt. Genau zu diesem Muster greifen die meisten Architekt:innen zu spät, nämlich erst, wenn eine synchrone Integration bereits einen Produktionsvorfall verursacht hat.

Wie wählen Sie das richtige Integrationsmuster?

Prüfen Sie jede Integrationsentscheidung entlang von sechs Dimensionen, bevor eine Zeile Code entsteht: zeitliche Anforderungen, Datenhoheit, Datenvolumen, Transaktionsbedarf, Verhalten im Fehlerfall und Latenz-SLA. Wer diesen Schritt überspringt, landet dabei, sechs Monate später einen Event-Bus an etwas anzuflanschen, das als synchroner Aufruf gebaut wurde.

Zeitliche Anforderungen klären, ob der Geschäftsprozess das Ergebnis sofort braucht oder eine Verzögerung verträgt. Eine Preisauskunft beim Checkout ist etwas anderes als eine monatliche Provisionsberechnung. Datenhoheit klärt, welches System die Quelle der Wahrheit ist. Wenn Salesforce für den Preiskatalog nicht führend ist, replizieren Sie ihn nicht nach Salesforce in der Hoffnung, er bleibe aktuell. Datenvolumen, teils als LDV (Large Data Volumes) bezeichnet, entscheidet darüber, ob Sie Bulk API und asynchrone Jobs statt transaktionaler Verfahren brauchen.

Transaktionsbedarf beschreibt, ob eine Operation als Ganzes gelingen oder scheitern muss. Verhalten im Fehlerfall klärt, was passiert, wenn ein nachgelagertes System nicht erreichbar ist. Wird der Datensatz für eine Wiederholung in die Warteschlange gestellt, sieht die Nutzerin einen Fehler, oder geht der Datensatz verloren? Das Latenz-SLA ist die Obergrenze für die akzeptable Antwortzeit, und sie muss aus dem Geschäft kommen, nicht daraus, was sich bequem bauen lässt.

Einige Szenarien lassen sich klar zuordnen:

• Eine Servicetechnikerin, die vor dem Einsatz den Lagerbestand in Echtzeit prüft, braucht Request and Reply oder, bei hohem Volumen, Datenvirtualisierung über Salesforce Connect.

• Eine abgeschlossene Opportunity, die eine Slack-Benachrichtigung, eine ERP-Bestellung und eine Markierung in der Marketing-Automation auslösen soll, passt zu Publish and Subscribe mit Platform Events, da drei getrennte Systeme dasselbe Signal brauchen.

• Ein nächtlicher Abgleich des Produktkatalogs aus einem ERP-System gehört in einen Batch Data Sync über die Bulk API, nicht in einen Echtzeitaufruf bei jedem Speichern.

• Ein Partnerportal, das während der Geschäftszeiten Leads nach Salesforce schreibt, ist ein Fall für Remote Call-In, abgesichert über eine eng gefasste Connected App.

Für den Workshop hält eine kurze Checkliste das Gespräch am Boden: Wie lautet das Latenz-SLA, in Sekunden oder Stunden? Wem gehört der Datensatz nach dieser Transaktion? Welches Tagesvolumen ist zu erwarten? Was passiert im Fehlerfall: Wiederholung, Alarm oder Verwerfen? Braucht es eine garantiert einmalige Zustellung, oder ist der Umgang mit Duplikaten nachgelagert vertretbar? Beantworten Sie diese fünf Fragen, bevor Sie den Musterkatalog aufschlagen, und die richtige Wahl liegt meist auf der Hand.

Synchron oder asynchron integrieren?

Wählen Sie standardmässig asynchron, ausser die Nutzerin wartet aktiv am Bildschirm auf das Ergebnis. Diese eine Regel verhindert die meisten Probleme mit Governor Limits und Sperren, auf die Architekt:innen nach dem Go-live stossen.

Synchrone Integrationen wirken einfacher zu bauen, und genau deshalb greifen Teams darauf zurück, selbst wenn der Geschäftsfall es gar nicht verlangt. Salesforce selbst nennt in seiner Übersicht zu häufigen Architekturfehlern das übermässige Vertrauen auf synchrone Aufrufe als wiederkehrendes Fehlermuster, meist weil niemand das tatsächliche SLA geprüft hat, bevor die Integration geschrieben wurde. Ein synchroner Aufruf, der eine Salesforce-Transaktion blockiert, während er auf eine langsame externe API wartet, riskiert das CPU-Zeitlimit. Und wenn dieses externe System zusätzlich in dieselben Datensätze zurückschreibt, entsteht ein Sperrkonflikt, der sich unter Last als scheinbar zufällige UNABLE_TO_LOCK_ROW-Fehler zeigt.

Die Entkopplung sieht fast immer gleich aus: Nehmen Sie den Schreibvorgang vom kritischen Pfad. Veröffentlichen Sie ein Platform Event, statt direkt aufzurufen, lassen Sie einen Abonnenten es asynchron verarbeiten, und geben Sie der Nutzerin eine sofortige Bestätigung statt eines Ladekreisels. Change Data Capture eignet sich gut, wenn Sie auf Datensatzänderungen reagieren müssen, ohne für jedes Objekt eigene Trigger-Logik zu schreiben, denn es veröffentlicht Änderungsereignisse automatisch anhand der Abonnements. Die Pub/Sub API ist der neuere, auf Protocol Buffers basierende Kanal, der Veröffentlichen und Abonnieren in grossem Massstab unterstützt, und sie ist der empfohlene Weg für Ereignisströme mit hohem Durchsatz.

Ein paar Faustregeln bewähren sich in den meisten Projekten:

• Wenn jemand am Bildschirm auf das Ergebnis wartet, ist synchron vermutlich richtig.

• Wenn drei oder mehr Systeme von demselben Ereignis wissen müssen, schlägt Publish and Subscribe drei getrennte Punkt-zu-Punkt-Aufrufe.

• Wenn das Volumen unvorhersehbar ausschlagen kann, fängt ein asynchroner Ansatz mit Warteschlange die Spitze ab; synchron läuft einfach in die Zeitüberschreitung.

• Wenn die Verfügbarkeit des externen Systems schlechter ist als jene von Salesforce, darf sein Ausfall Salesforce nicht mitreissen.

Profi-Tipp: Behalten Sie Ihr API-Aufrufbudget im Blick, wenn Sie Ereignisse über den REST-API-Endpunkt statt nativ über Apex oder Flow veröffentlichen. Aus der Community heisst es, dass über die API veröffentlichte Ereignisse auf das Tageslimit angerechnet werden, native Veröffentlichungswege dagegen nicht. Dieser Unterschied fällt stark ins Gewicht, sobald Sie täglich Tausende Ereignisse veröffentlichen.

Replikation oder Virtualisierung: Welche Datenstrategie gewinnt?

Kopieren Sie Daten nach Salesforce, wenn sie innerhalb der Plattform schnell, abfragbar und auswertbar sein müssen. Lassen Sie sie extern und fragen Sie bei Bedarf ab, wenn sie sich zu häufig ändern, um synchron gehalten zu werden, oder wenn eine Duplizierung Compliance-Probleme schafft.

Replikation heisst, eine Kopie externer Daten als Salesforce-Datensätze zu speichern, aktualisiert nach Zeitplan oder über Ereignisse. Das ist richtig für alles, worüber Nutzer:innen in Salesforce Berichte erstellen oder worauf sie in Flows und Validierungsregeln zugreifen, denn virtualisierte Daten unterstützen das nicht immer nativ. Virtualisierung über Salesforce Connect und externe Objekte spart die Kopie und fragt das Quellsystem direkt ab. Sie passt zu grossen, sich ständig ändernden Katalogen, etwa der Echtzeit-Preistabelle eines Distributors, wo eine synchrone Kopie ständige Sync-Jobs bedeuten würde, die Aktualität gegen Speicherkosten ausspielen.

Zero-Copy-Ansätze gehen noch weiter. Die Salesforce-Empfehlungen zu Integrationsmustern für Data 360 beschreiben Aufnahmemodi, mit denen Data Cloud Daten an Ort und Stelle referenziert, statt sie über jedes verbundene System hinweg zu duplizieren. Das zählt, wenn ein Data Warehouse und Salesforce denselben Kundendatensatz brauchen, ohne zu zwei Quellen der Wahrheit zu werden.

Die Hoheit über Stammdaten muss geklärt sein, bevor der erste Sync-Job geschrieben wird, nicht danach. Legen Sie von Anfang an fest, welches System für welche Entität führend ist, für Kunde, Produkt, Preis, und halten Sie das als Schema-Vertrag fest, den beide Teams abnehmen. Die Dublettenlogik gehört an den Punkt der Datenaufnahme, nicht in einen Aufräum-Job sechs Monate später, wenn doppelte Accounts bereits jeden nachgelagerten Bericht verunreinigt haben.

Ein paar praktische Leitplanken:

• Behandeln Sie das Schema als Vertrag zwischen den Systemen; eine Änderung des Feldtyps auf einer der beiden Seiten sollte eine Freigabe erfordern, nicht bloss einen Deploy.

• Nutzen Sie Salesforce Connect für lesestarke externe Daten mit toleranter Latenz, statt sie zu replizieren.

• Greifen Sie zu Data Cloud, wenn Sie ein einheitliches Kundenprofil über viele Quellsysteme brauchen, nicht als allgemeinen ETL-Ersatz.

• Holen Sie Middleware ins Spiel, wenn die Transformationslogik zwischen Systemen so komplex wird, dass Apex zu einer nicht mehr wartbaren Mapping-Schicht verkommt.

Bei Ladevorgängen mit grossen Datenmengen justieren Sie die Stapelgrösse der Bulk API ausgehend von etwa 200 Datensätzen und passen sie an die Parallelitätsgrenzen des Zielsystems an, denn pushing too hard against a partner’s ingestion rate verschiebt den Engpass nur, statt ihn zu lösen.

Welche Sicherheitsmassnahmen braucht jede Integration?

Keine einzigen Zugangsdaten im Code, jede OAuth-Berechtigung so eng wie möglich, und Tokens nach Plan erneuern, nicht erst, wenn etwas kaputtgeht. Das ist die Grundlinie, und Integrationen, die sie überspringen, tauchen später in Vorfallberichten auf.

Named Credentials gibt es, damit Sie nie eine Endpunkt-URL oder ein Authentifizierungs-Token fest in Apex schreiben. Sie bündeln die Verbindungsdetails und überlassen Salesforce den OAuth-Ablauf, womit ein Wechsel der Zugangsdaten auch kein Code-Deployment mehr braucht. External Client Apps sind der moderne Ersatz für die alte Connected-App-Konfiguration, und das Spring-'26-Release von Salesforce hat die Migration älterer Setups stark vorangetrieben. Von der Community gepflegte security best-practice references halten unmissverständlich fest, dass fest verdrahtete Geheimnisse und zu breit gefasste OAuth-Berechtigungen die beiden häufigsten Befunde in Sicherheitsprüfungen von Integrationen sind.

Speziell zu OAuth: Beschränken Sie die Berechtigungen exakt auf das, was die Integration braucht, keinen Deut mehr. Nutzen Sie den JWT-Bearer-Flow für Server-zu-Server-Integrationen, bei denen niemand interaktiv authentifiziert. Nutzen Sie PKCE für jeden öffentlichen Client, etwa eine mobile App, bei der sich ein Client Secret nicht sicher ablegen lässt. Erneuern Sie Tokens nach einem festen Zeitplan, statt langlebige Tokens unbegrenzt aktiv zu lassen.

Ein breit anerkanntes Muster aus der Praxis: Integrationen, die Zugangsdaten über benannte Verbindungen zentral verwalten statt über eingebettete Geheimnisse, verzeichnen deutlich weniger Vorfälle durch abgeflossene oder veraltete Tokens, weil die Erneuerung zur Konfigurationsänderung wird statt zum Code-Deploy.

Über die Identität hinaus runden ein paar Netzwerk- und Compliance-Massnahmen die Checkliste ab:

• Beschränken Sie Remote Site Settings auf genau die Domains, die eine Integration braucht, nicht auf einen Platzhalter.

• Verfolgen Sie Ablaufdaten von Zertifikaten zentral; ein abgelaufenes Zertifikat, das über Nacht still eine Integration lahmlegt, gehört zu den häufigsten selbst verschuldeten Ausfällen.

• Verschlüsseln Sie personenbezogene Daten sowohl bei der Übertragung als auch bei der Speicherung, überall dort, wo die Integration sie berührt.

• Dokumentieren Sie Datenflüsse für die DSGVO oder vergleichbare Regelwerke, besonders wenn Personendaten zwischen Systemen eine Landesgrenze überschreiten.

Wie bauen Sie robuste und beobachtbare Integrationen?

Gehen Sie davon aus, dass jeder nachgelagerte Aufruf irgendwann scheitert, und entwerfen Sie Wiederholungen, Alarmierung und Idempotenz vor dem Gutfall, nicht nach dem ersten Ausfall.

Die Wiederholungsstrategie sollte exponentielles Backoff mit Jitter nutzen, keine festen Intervalle, bei denen alle Versuche gleichzeitig auf das ausgefallene System treffen und den Ausfall verschärfen. Ein typisches Muster: nach 2 Sekunden erneut versuchen, dann nach 4, dann nach 8, jeweils mit einem kleinen zufälligen Versatz und einer definierten Obergrenze, bevor aufgegeben wird. Circuit Breaker stoppen die Aufrufe eines nachgelagerten Systems vollständig, sobald es ein Fehlermuster zeigt, und geben ihm Luft zur Erholung, statt es mit Wiederholungen aus jeder abhängigen Integration zu überfahren. Dead-Letter-Queues fangen alles auf, was seine Wiederholungen aufgebraucht hat, damit fehlgeschlagene Nachrichten geprüft und manuell erneut verarbeitet werden, statt zu verschwinden.

Idempotenz zählt am meisten in genau den Situationen, in denen Wiederholungen auftreten: Wird eine Nachricht zweimal verarbeitet, weil eine Bestätigung verloren ging, darf der zweite Durchlauf keinen doppelten Datensatz erzeugen. Der Standardweg sind Transaktions-IDs, die jede Nachricht mitführt und die auf der Empfängerseite gegen eine Eindeutigkeitsbedingung geprüft werden. Die Ereignisarchitektur von Salesforce unterstützt das gut: Wiederholbare Ereignisse mit Replay-IDs erlauben es einem Abonnenten, der Nachrichten verpasst hat, ab einem bekannten Punkt aufzuholen, statt zu raten, was ihm fehlt.

Beobachtbarkeit schliesst den Kreis. Zentrale Protokollierung über jedes System der Integrationskette hinweg, verteiltes Tracing, damit eine einzelne Transaktion durchgängig verfolgt werden kann, und Dashboards für Fehlerrate, Latenz-Perzentile und Warteschlangenlänge gehören ab Tag eins ins Design, nicht erst nachträglich nach dem ersten Produktionsvorfall.

Eine kurze Betriebsliste, die sichtbar bleiben sollte:

• Wiederholen mit exponentiellem Backoff und Jitter, begrenzt auf eine vernünftige Höchstzahl an Versuchen.

• Aufgebrauchte Wiederholungen mit Alarm in eine Dead-Letter-Queue leiten, nicht stillschweigend verwerfen.

• Jeder Nachricht eine eindeutige Transaktions-ID mitgeben und diese nachgelagert als Eindeutigkeitsbedingung durchsetzen.

• Fehlerrate, p95-Latenz und Warteschlangenlänge als dauerhafte Kennzahlen verfolgen, nicht nur die Verfügbarkeit.

Profi-Tipp: Testen Sie Ihre Wiederholungs- und Dead-Letter-Logik in einer Staging-Umgebung, indem Sie ein nachgelagertes Mock-System mitten im Lauf bewusst abschalten. Die meisten Teams merken erst bei einem echten Ausfall, dass ihre Backoff-Logik defekt ist, und das ist der denkbar schlechteste Zeitpunkt.

Wann sollten Sie Middleware statt nativer Salesforce-Werkzeuge einsetzen?

Greifen Sie zu Middleware, also einer Integrationsplattform (iPaaS), einem Enterprise Service Bus oder einem API-Gateway, sobald Orchestrierung über mehr als zwei Systeme, Protokollübersetzung oder zentrale Durchsetzung von Richtlinien ins Spiel kommt. Native Salesforce-Werkzeuge leisten für sich genommen viel, waren aber nie als Orchestrierungsschicht für einen Ablauf über fünf Systeme gedacht.

Middleware verdient ihren Platz über eine klar umrissene Rolle: Orchestrierung mehrerer nachgelagerter Aufrufe in definierter Reihenfolge, Protokollvermittlung, wenn ein System SOAP spricht und ein anderes REST oder ein Message-Queue-Protokoll, Drosselung, um Systeme mit geringerer Kapazität als Salesforce zu schützen, Transformation von Nutzdaten zwischen unvereinbaren Datenmodellen und Durchsetzung von Richtlinien wie Ratenbegrenzung oder Authentifizierungsprüfungen, einheitlich über alle Integrationen hinweg statt in jeder einzeln nachgebaut.

Native Salesforce-Integration über Platform Events, Apex REST oder eine direkte Connected App funktioniert bestens für einfache Punkt-zu-Punkt-Verbindungen zwischen zwei Systemen, wo es diese Orchestrierungskomplexität gar nicht gibt. Sobald ein drittes System hinzukommt oder sich Transformationslogik über mehrere Apex-Klassen erstreckt, nur um Nutzdaten umzuformen, ist das das Signal, die Logik in die Middleware zu verlagern, statt sie in der Org wuchern zu lassen.

APIs nach Verantwortlichkeit zu schichten zahlt sich aus, wenn die Zahl der Integrationen wächst. System-APIs kapseln ein einzelnes Backend-System hinter einer stabilen Schnittstelle. Prozess-APIs setzen mehrere System-APIs zu einer fachlichen Operation zusammen. Experience-APIs formen Daten für einen bestimmten Kanal auf: mobil, Web, Partnerportal. Dokumentation zur API-First-Integrationsarchitektur beschreibt diese Schichtung als den Unterschied zwischen Integrationen, die über Projekte hinweg wiederverwendet werden, und solchen, die bei jedem neuen Konsumenten von Grund auf neu gebaut werden.

• Setzen Sie middleware ein, wenn drei oder mehr Systeme für einen einzigen Geschäftsprozess koordiniert orchestriert werden müssen.

• Bleiben Sie nativ, wenn die Integration eine einfache Verbindung zwischen zwei Systemen mit geringem Volumen ist.

• Schichten Sie APIs nach System, Prozess und Experience, um die Wiederverwendung in künftigen Projekten zu maximieren.

Was gehört auf die Integrations-Checkliste einer Architektin oder eines Architekten?

Ein Design-Review, das Verantwortlichkeit, Rollback und Überwachung am ersten Tag auslässt, ist ein Design-Review, das später einen Vorfall produziert. Eine gründliche Checkliste vor Beginn der Umsetzung lohnt sich als fester Bestandteil jedes Integrationsmandats.

Punkte fürs Design-Review: Dokumentieren Sie die groben Anforderungen und das geschäftliche SLA, bevor Sie ein Muster wählen. Halten Sie für jede nicht triviale Entscheidung einen Architecture Decision Record fest, synchron gegen asynchron, Replikation gegen Virtualisierung, damit die Begründung einen Personalwechsel überlebt. Legen Sie für jedes eingebundene System eine klare Verantwortlichkeit fest, inklusive der Frage, wer bei einer Störung alarmiert wird. Definieren Sie einen Rollback-Plan vor der Inbetriebnahme, nicht mitten im Vorfall.

Punkte für die CI/CD-Prüfung: Automatisieren Sie Tests der OAuth-Redirect-URIs, damit eine Konfigurationsänderung die Authentifizierung nicht still in der Produktion zerlegt. Prüfen Sie Ablaufdaten von Zertifikaten als Teil der Pipeline, nicht als manuelle Kalendererinnerung, denn die Identitätsänderungen in Spring '26 haben certificate lifecycle management a first-class operational concern gemacht statt einer Nebensache. Prüfen Sie als Freigabe-Kriterium vor dem Deployment, ob jeder externe Endpunkt korrekt antwortet, damit ein falsch konfiguriertes Named Credential auffällt, bevor es die Nutzer:innen erreicht.

Überwachungs-Runbooks: Legen Sie fest, was einen Alarm auslöst, wer ihn erhält und welches die ersten drei Schritte zur Fehlersuche sind, schriftlich vor dem Go-live, nicht improvisiert während des ersten Ausfalls.

• Halten Sie für jede im Design getroffene Musterentscheidung einen Architecture Decision Record fest.

• Führen Sie automatisierte OAuth- und Zertifikatsprüfungen als Freigabe-Kriterium vor dem Deployment aus, nicht als manuellen Schritt.

• Benennen Sie für jedes eingebundene System eine verantwortliche Person und einen Eskalationsweg.

• Schreiben Sie den Rollback-Plan vor dem ersten Deployment, nicht nach dem ersten Fehlschlag.

Unsere Sicht darauf, wo Integrationsprojekte wirklich scheitern

Die meisten Integrationsfehler, die uns in Audits begegnen, gehen auf Entscheidungen zurück, die damals vernünftig wirkten: aus Tempogründen synchron bauen, wegen knapper Fristen auf Architecture Decision Records verzichten, oder für eine schnelle Integration Tokens fest verdrahten statt sie ordentlich zu verwalten. Nichts davon ist Unwissen. Es sind kleine, für sich genommen vertretbare Abkürzungen, die sich summieren.

Der Musterkatalog und die Sicherheitscheckliste in diesem Leitfaden sind praxiserprobte Prüfungen aus Integrationsmandaten, von unkomplizierten ERP-Abgleichen bis zu Ereignisarchitekturen über mehrere Systeme. Frühe Senior-Beteiligung am Architekturgespräch, nicht erst bei der Übergabe, hilft, verfrühte synchrone Aufrufe vor der Inbetriebnahme zu erkennen. Ein typisches Mandat läuft über Audit, dann Plan, dann Umsetzung, dann laufenden Support, und der grösste Wert entsteht meist im ersten Schritt, dem Audit, wo die Lücke zwischen dem, was ein System leisten sollte, und dem, was es tatsächlich tut, sichtbar wird.

Wenn Sie auf eine Altintegration schauen, der niemand mehr ganz traut, oder auf ein neues Projekt, bei dem die Musterwahl noch unsicher wirkt, dann ist das der richtige Moment für eine externe Architekturprüfung, bevor weiterer Code auf einem unklaren Fundament entsteht.

Wie Ampersand Labs Salesforce-Integrationsprojekte unterstützt

Die richtige Integrationsarchitektur gleich beim ersten Mal zu bauen kostet weniger, als eine synchrone, fest verdrahtete Lösung zu entwirren, wenn sie bereits produktiv und tragend ist. Mandate für Salesforce-Integration und API-Entwicklung profitieren davon, dass Senior-Architekt:innen ab dem ersten Workshop dabei sind und nicht erst nach Vertragsunterzeichnung. So fallen Fehler bei der Musterwahl früh auf statt in der Produktion.

Ein typisches Mandat kann ein Audit der bestehenden Integrationslandschaft umfassen, einen Machbarkeitsnachweis für riskante Musterentscheidungen, die Umsetzung sowie laufenden Support, damit die Architektur wartbar bleibt, wenn neue Systeme dazukommen. Zu den Leistungen können Systemintegrationen, API-Entwicklung, Interim-CTO-Unterstützung, CI/CD- und Sicherheitsaudits sowie KI-Automatisierung für Abläufe rund um Salesforce-Daten gehören.

Wenn sich eine bestehende Integration brüchig anfühlt oder Sie gerade eine entwerfen und vor dem ersten Code ein zweites, erfahrenes Augenpaar auf die Musterwahl werfen lassen möchten, starten Sie auf der Seite zu Systemintegration & API-Entwicklung und sehen Sie, wie ein Audit- und Umsetzungsmandat zugeschnitten wird.

Quellen

• three-way split and a selection matrix

• Salesforce blog’s own guidance on aligning patterns to use cases

• security best-practice references

• certificate lifecycle management a first-class operational concern

FAQ

Was sind die besten Werkzeuge für Salesforce-Integrationen?

Platform Events, Change Data Capture und die Pub/Sub API decken die meisten ereignisgesteuerten Szenarien ab, während Named Credentials und Salesforce Connect sichere Verbindungen und Datenvirtualisierung übernehmen. Für die Orchestrierung über mehr als zwei Systeme hinweg ist eine Integrationsplattform (iPaaS) oder ein API-Gateway den nativen Werkzeugen allein in der Regel überlegen.

Welche bewährten Vorgehensweisen gelten für die Salesforce-Entwicklung in Integrationsprojekten?

Entwerfen Sie vor dem Programmieren entlang eines Rahmens zur Musterwahl, wählen Sie standardmässig asynchrone Verfahren für alles, was über eine einfache Verbindung zweier Systeme hinausgeht, und sichern Sie jede Zugangsberechtigung über Named Credentials statt fest verdrahteter Tokens. Bauen Sie Idempotenz und Wiederholungslogik von Anfang an ein, statt sie nach dem ersten Ausfall in der Produktion nachzurüsten.

Wie verbinden Sie Salesforce mit einer anderen Salesforce-Org?

Für die Integration von Org zu Org kommen üblicherweise Platform Events oder Change Data Capture für nahezu echtzeitnahe Synchronisation zum Einsatz, oder die Bulk API für geplante Stapelübertragungen grösserer Datenmengen. Named Credentials auf beiden Orgs, kombiniert mit einer Connected App oder External Client App über OAuth, halten die Verbindung sicher, ohne Geheimnisse fest zu verdrahten.

Was unterscheidet Change Data Capture von Platform Events?

Change Data Capture veröffentlicht Änderungsereignisse automatisch, sobald Datensätze eines abonnierten Objekts erstellt, aktualisiert, gelöscht oder wiederhergestellt werden, ganz ohne eigene Trigger-Logik. Platform Events sind selbst definierte Ereignisse, die Sie aus Apex, Flow oder einem externen System explizit für jedes beliebige Geschäftsereignis veröffentlichen, nicht nur für Datensatzänderungen.

Wann setzen Sie Salesforce Connect statt Datenreplikation ein?

Nutzen Sie Salesforce Connect, wenn sich externe Daten zu häufig ändern, um eine synchrone Kopie aktuell zu halten, oder wenn deren Duplizierung Bedenken bei Speicher oder Compliance auslöst. Wählen Sie stattdessen die Replikation, wenn Nutzer:innen die Daten innerhalb von Salesforce auswerten oder in Flows und Validierungsregeln referenzieren müssen, was virtualisierte Objekte nicht vollständig unterstützen.

Empfohlen

• Systemintegration & API-Entwicklung Zürich

• KI-Automatisierung & Workflow-Agenten Zürich