Salesforce Integration: APIs und Connected Apps für KMU erklärt

Kein CRM ist eine Insel – warum Integration entscheidend ist

Du hast Salesforce eingeführt, dein Vertriebsteam arbeitet damit, die Pipeline ist sauber aufgesetzt – und trotzdem fühlt es sich an, als würdest du nur einen Bruchteil der Möglichkeiten nutzen. Das ist keine Einbildung. Denn ein CRM, das isoliert betrieben wird, ist wie ein Gehirn ohne Nervenbahnen: Es kann Informationen speichern, aber nicht mit dem Rest des Körpers kommunizieren.

In der Realität arbeiten KMU mit einer Vielzahl von Systemen: Buchhaltungssoftware wie DATEV oder lexoffice, E-Mail-Marketing-Tools wie Mailchimp oder ActiveCampaign, Projektmanagement-Plattformen wie Jira oder Asana, vielleicht ein ERP-System, ein Ticketing-Tool für den Kundenservice, eine E-Commerce-Plattform. Jedes dieser Systeme erzeugt wertvolle Daten – und jedes dieser Systeme profitiert davon, wenn es Zugriff auf die CRM-Daten hat.

Die Integration dieser Systeme ist kein Nice-to-have, sondern ein strategischer Hebel. Wenn dein Vertriebsteam in Salesforce sehen kann, welche Rechnungen ein Kunde offen hat, welche Support-Tickets laufen und welche Marketing-Kampagnen er angeklickt hat, trifft es bessere Entscheidungen. Wenn dein Marketing-Team automatisch informiert wird, sobald ein Lead im CRM einen bestimmten Status erreicht, kann es gezielter nachfassen. Und wenn dein Projektmanagement-Tool automatisch ein Projekt anlegt, sobald eine Opportunity auf "Closed Won" wechselt, sparst du manuelle Arbeit und vermeidest Fehler.

Die Frage ist also nicht ob du Salesforce integrieren solltest, sondern wie. Und genau darum geht es in diesem Artikel.

Integrations-Ansätze im Überblick

Bevor wir in die technischen Details der Salesforce APIs eintauchen, schauen wir uns die drei grundlegenden Ansätze an, mit denen du Salesforce mit anderen Systemen verbinden kannst. Jeder hat seine Berechtigung – und seine optimalen Einsatzszenarien.

Native Integrationen über AppExchange

Der Salesforce AppExchange ist der größte Marktplatz für Business-Apps im CRM-Umfeld. Hier findest du tausende vorgefertigte Integrationen, die von Drittanbietern oder Salesforce selbst entwickelt wurden. Beispiele: die offizielle Mailchimp-Integration, der DATEV-Connector von verschiedenen Anbietern oder die Jira-Integration von Atlassian.

Der Vorteil: Du installierst die App, konfigurierst sie, und die Integration läuft. Kein Code, kein API-Wissen nötig. Die Apps sind in der Regel gut dokumentiert, werden regelmäßig aktualisiert und haben Support-Kanäle. Für Standard-Integrationsszenarien ist das oft der schnellste und günstigste Weg.

Der Nachteil: Du bist auf die Funktionalität beschränkt, die der App-Entwickler vorgesehen hat. Wenn du spezifische Anforderungen hast – etwa nur bestimmte Felder synchronisieren willst oder eine komplexe Mapping-Logik brauchst – stößt du schnell an Grenzen. Außerdem können AppExchange-Apps zusätzliche Lizenzkosten verursachen, die sich summieren.

Middleware-Plattformen (MuleSoft, Zapier, Make)

Middleware-Plattformen – auch iPaaS (Integration Platform as a Service) genannt – sitzen zwischen deinen Systemen und orchestrieren den Datenaustausch. Du definierst Trigger ("Wenn in Salesforce ein neuer Kontakt erstellt wird...") und Aktionen ("...dann erstelle einen Kontakt in Mailchimp"), und die Plattform kümmert sich um die Ausführung.

Der Vorteil: Deutlich flexibler als native Integrationen. Du kannst komplexe Workflows bauen, Daten transformieren, Bedingungen definieren und mehrere Systeme in einem Flow verbinden. Gleichzeitig brauchst du (je nach Plattform) wenig bis gar keinen Code. Zapier und Make haben visuelle Builder, die auch technisch weniger versierte Nutzer bedienen können.

Der Nachteil: Laufende Kosten, die mit der Anzahl der Ausführungen skalieren. Bei hohen Datenvolumen kann das teuer werden. Außerdem bist du von der Middleware-Plattform als zusätzlichem System abhängig – ein weiterer Single Point of Failure in deiner Architektur.

Custom API-Integration

Wenn weder native Apps noch Middleware deine Anforderungen abdecken, bleibt die Custom-Integration über die Salesforce APIs. Hier schreibst du (oder dein Entwickler) Code, der direkt mit der Salesforce API kommuniziert – Daten liest, schreibt, aktualisiert oder löscht.

Der Vorteil: Maximale Flexibilität. Du kannst exakt die Integration bauen, die du brauchst – mit beliebiger Logik, beliebigem Timing, beliebiger Datentransformation. Keine Einschränkungen durch Drittanbieter-Apps oder Middleware-Limits.

Der Nachteil: Du brauchst Entwickler-Ressourcen, und du bist selbst für Wartung, Monitoring und Fehlerbehandlung verantwortlich. Für KMU ohne eigene Entwicklungsabteilung ist das oft nicht wirtschaftlich – es sei denn, es handelt sich um eine geschäftskritische Integration, die genau so funktionieren muss.

Wann welchen Ansatz wählen?

Als Faustregel gilt: Starte mit nativen Integrationen aus dem AppExchange. Wenn die nicht reichen, prüfe Middleware-Plattformen. Erst wenn auch die nicht genügen, baue eine Custom-Integration. Dieser Ansatz minimiert Kosten und Komplexität, ohne dich in deinen Möglichkeiten einzuschränken. In der Praxis setzen die meisten KMU eine Kombination aus allen drei Ansätzen ein – native Apps für die Standard-Fälle, Middleware für spezifischere Flows und gelegentlich eine Custom-Integration für den einen geschäftskritischen Prozess, der exakt so laufen muss.

Salesforce APIs verstehen

Salesforce bietet nicht eine API, sondern ein ganzes Bündel spezialisierter APIs für unterschiedliche Anwendungsfälle. Als KMU musst du nicht alle kennen, aber ein grundlegendes Verständnis der wichtigsten APIs hilft dir, die richtigen Entscheidungen bei der Integration zu treffen – auch wenn du die technische Umsetzung an einen Dienstleister übergibst.

REST API – der Standard für CRUD-Operationen

Die REST API ist die am häufigsten genutzte Salesforce API und dein Hauptwerkzeug für Standardintegrationen. REST steht für Representational State Transfer und ist ein weit verbreiteter Architekturstil für Web-APIs. Mit der REST API kannst du die typischen CRUD-Operationen durchführen: Create (Datensätze erstellen), Read (Daten abfragen), Update (Daten aktualisieren) und Delete (Daten löschen).

Ein typischer Anwendungsfall: Dein Webformular sendet eine Anfrage an die Salesforce REST API, um einen neuen Lead anzulegen. Oder dein Buchhaltungssystem fragt regelmäßig die REST API ab, um neue Kontaktdaten zu synchronisieren. Die REST API arbeitet mit JSON als Datenformat, ist gut dokumentiert und wird von praktisch jeder Programmiersprache und Plattform unterstützt.

Bulk API – für große Datenmengen

Wenn du nicht einzelne Datensätze, sondern tausende oder hunderttausende auf einmal verarbeiten musst, ist die Bulk API dein Werkzeug. Sie ist optimiert für Massenoperationen und arbeitet asynchron: Du schickst einen Job mit allen Datensätzen ab, und Salesforce verarbeitet ihn im Hintergrund. Du fragst dann den Status ab, bis der Job abgeschlossen ist.

Typische Anwendungsfälle: initiale Datenmigration beim Systemwechsel, regelmäßige Massenaktualisierungen (z.B. nächtlicher Abgleich von Kundendaten zwischen ERP und Salesforce) oder der Import großer Lead-Listen aus externen Quellen. Die Bulk API ist deutlich effizienter als die REST API für diese Szenarien, weil sie weniger API-Calls verbraucht und für Durchsatz optimiert ist.

Streaming API – für Echtzeit-Events

Die Streaming API löst ein fundamentales Problem: Wie erfährst du in Echtzeit, wenn sich etwas in Salesforce ändert? Statt die REST API im Sekundentakt abzufragen (Polling), kannst du mit der Streaming API einen Kanal abonnieren und wirst automatisch benachrichtigt, sobald ein relevantes Event eintritt.

Ein konkretes Beispiel: Du möchtest, dass dein Projektmanagement-Tool sofort informiert wird, wenn eine Opportunity in Salesforce auf "Closed Won" gesetzt wird. Mit der Streaming API abonnierst du Änderungen am Opportunity-Objekt und erhältst in Echtzeit eine Benachrichtigung, wenn das Feld "Stage" auf "Closed Won" wechselt. Das ist schneller und effizienter als Polling, verbraucht weniger API-Calls und liefert eine bessere User Experience.

Composite API – mehrere Operationen in einem Call

Die Composite API ermöglicht es dir, mehrere API-Operationen in einem einzigen HTTP-Request zu bündeln. Das ist besonders nützlich, wenn du zusammengehörige Datensätze erstellen musst – etwa einen Account, einen zugehörigen Contact und eine Opportunity in einem Schritt.

Ohne die Composite API bräuchtest du drei separate API-Calls, müsstest nach jedem Call die ID des erstellten Datensatzes abfragen und im nächsten Call referenzieren. Mit der Composite API definierst du alle drei Operationen in einem Request und kannst innerhalb des Requests auf die Ergebnisse vorheriger Operationen verweisen. Das spart API-Calls, reduziert Latenz und macht die Integration robuster, weil entweder alle Operationen erfolgreich sind oder keine.

API-Limits und Monitoring

Ein Thema, das viele KMU unterschätzen: Salesforce hat API-Limits. Je nach Edition und Lizenztyp hast du ein bestimmtes Kontingent an API-Calls pro 24-Stunden-Zeitraum. Für die Professional Edition sind das beispielsweise 100.000 Calls pro Tag, für die Enterprise Edition 1.000.000. Das klingt viel, kann aber bei schlecht designten Integrationen schnell knapp werden – etwa wenn ein System im Sekundentakt Polling betreibt oder bei jeder Änderung mehrere unnötige API-Calls auslöst.

Deshalb ist API-Monitoring Pflicht. In Salesforce findest du unter Setup > System Overview und Setup > API Usage Notifications die Tools, um deinen API-Verbrauch zu überwachen. Richte Benachrichtigungen ein, die dich warnen, wenn du dich deinem Limit näherst. Und optimiere deine Integrationen von Anfang an: Nutze die Bulk API für Massenoperationen, die Composite API für zusammengehörige Operationen und die Streaming API statt Polling für Echtzeit-Szenarien.

Connected Apps einrichten

Was ist eine Connected App?

Eine Connected App ist die Brücke zwischen einer externen Anwendung und deiner Salesforce-Org. Sie definiert, welche externe Anwendung auf deine Salesforce-Daten zugreifen darf, wie sie sich authentifiziert und welche Berechtigungen sie hat. Jede Integration, die über die Salesforce API läuft – egal ob Custom-Code, Middleware oder eine Drittanbieter-App – braucht eine Connected App als Authentifizierungsgrundlage.

Stell dir eine Connected App wie einen Ausweis vor: Sie identifiziert die externe Anwendung eindeutig und legt fest, welche Türen sie öffnen darf. Ohne Connected App keine API-Kommunikation.

OAuth 2.0 Authentifizierung

Salesforce nutzt OAuth 2.0 als Authentifizierungsstandard für Connected Apps. OAuth 2.0 ist ein branchenweiter Standard, der es einer Anwendung ermöglicht, im Namen eines Benutzers auf Ressourcen zuzugreifen, ohne dass der Benutzer seine Zugangsdaten an die Anwendung weitergeben muss.

Der Ablauf in Kurzform: Die externe Anwendung leitet den Benutzer zur Salesforce-Login-Seite weiter. Der Benutzer meldet sich an und autorisiert den Zugriff. Salesforce gibt einen Access Token und einen Refresh Token zurück. Die externe Anwendung nutzt den Access Token für API-Calls. Wenn der Access Token abläuft, wird er mit dem Refresh Token erneuert. So bleiben die Salesforce-Zugangsdaten sicher, und du kannst den Zugriff jederzeit widerrufen, ohne Passwörter ändern zu müssen.

Schritt-für-Schritt Setup

Das Einrichten einer Connected App in Salesforce ist nicht kompliziert, erfordert aber Admin-Rechte und ein Verständnis der einzelnen Konfigurationsschritte. Hier der Ablauf:

Navigiere in Salesforce zu Setup und suche nach "App Manager". Klicke auf "New Connected App" oben rechts. Vergib einen aussagekräftigen Namen – zum Beispiel "Buchhaltung-Integration" oder "Mailchimp-Sync". Dieser Name hilft dir später, den Überblick zu behalten, wenn du mehrere Connected Apps hast.

Aktiviere OAuth Settings und setze den Callback URL. Der Callback URL ist die Adresse, an die Salesforce den Authorization Code nach der Anmeldung schickt. Bei Middleware-Plattformen wie Zapier oder Make wird dir der Callback URL von der Plattform vorgegeben. Bei Custom-Integrationen definierst du ihn selbst.

Wähle die OAuth Scopes – also die Berechtigungen, die die Connected App haben soll. Hier gilt das Prinzip der minimalen Rechte: Gib nur die Berechtigungen, die tatsächlich benötigt werden. Für eine Integration, die nur Daten liest, reicht "Access and manage your data (api)" und "Perform requests on your behalf at any time (refresh_token, offline_access)".

Speichere die Connected App. Salesforce generiert jetzt einen Consumer Key und ein Consumer Secret. Diese beiden Werte sind die Zugangsdaten deiner Integration – behandle sie wie Passwörter und speichere sie sicher.

Scopes und Berechtigungen

Die OAuth Scopes in Salesforce steuern granular, was eine Connected App tun darf. Die wichtigsten Scopes im Überblick:

• api: Zugriff auf die REST und SOAP API. Ohne diesen Scope kann die App keine API-Calls machen – das ist quasi der Basis-Scope für jede Integration.
• refresh_token: Erlaubt der App, den Access Token automatisch zu erneuern. Ohne diesen Scope müsste der Benutzer sich regelmäßig neu authentifizieren.
• full: Vollzugriff auf alle verfügbaren Ressourcen. Nutze diesen Scope nur, wenn es wirklich nötig ist – in der Praxis reichen meist spezifischere Scopes.
• chatter_api: Zugriff auf Chatter-Daten. Relevant, wenn die Integration mit dem internen Social Network arbeiten soll.
• wave_api: Zugriff auf Analytics-Daten. Relevant für BI-Integrationen.

Praxisbeispiel 1: Salesforce + Buchhaltung (DATEV/lexoffice)

Die Integration von CRM und Buchhaltung gehört zu den wertvollsten und gleichzeitig anspruchsvollsten Integrationen für KMU. Wenn sie funktioniert, sparst du manuelle Doppeleingaben, vermeidest Fehler und gibst deinem Vertriebsteam wertvolle finanzielle Einblicke direkt im CRM.

Rechnungsdaten synchronisieren

Der häufigste Anwendungsfall: Wenn in Salesforce eine Opportunity auf "Closed Won" gesetzt wird, soll automatisch eine Rechnung in der Buchhaltungssoftware erstellt werden. Dafür müssen die relevanten Daten aus der Opportunity (Rechnungsempfänger, Positionen, Beträge, Zahlungsbedingungen) an das Buchhaltungssystem übermittelt werden.

Bei lexoffice funktioniert das gut über die lexoffice API in Kombination mit einer Middleware wie Make. Du definierst einen Trigger in Salesforce (Stage Changed to Closed Won), die Middleware liest die Opportunity-Daten über die REST API, transformiert sie ins lexoffice-Format und erstellt die Rechnung über die lexoffice API. Bei DATEV ist die Situation etwas komplexer, da DATEV traditionell keine offene API bietet – hier arbeitet man oft mit Zwischenlösungen wie GetMyInvoices oder speziellen DATEV-Connectoren.

Kontaktdaten abgleichen

Ein zweiter wichtiger Aspekt: Die Stammdaten (Firmenname, Adresse, Ansprechpartner, Steuernummer) sollten zwischen CRM und Buchhaltung konsistent sein. Hier definierst du ein führendes System – typischerweise das CRM für Kontaktdaten – und synchronisierst Änderungen automatisch in die Buchhaltungssoftware. Wichtig dabei: Definiere klare Regeln für Konfliktfälle. Was passiert, wenn ein Kontakt in beiden Systemen gleichzeitig geändert wird? Welches System gewinnt?

Umsatzdaten zurückspielen

Die wertvollste Richtung der Integration wird oft vergessen: Umsatzdaten aus der Buchhaltung zurück ins CRM spielen. Wenn dein Vertriebsteam in Salesforce sehen kann, welchen Gesamtumsatz ein Kunde generiert hat, welche Rechnungen offen sind und wie das Zahlungsverhalten ist, kann es deutlich bessere Gespräche führen und Upselling-Potenziale erkennen. Dafür erstellst du Custom Fields oder ein Custom Object in Salesforce, das die Finanzdaten abbildet, und synchronisierst regelmäßig (z.B. täglich) die Daten aus der Buchhaltung.

Praxisbeispiel 2: Salesforce + E-Mail-Marketing (Mailchimp/ActiveCampaign)

Die Integration von CRM und E-Mail-Marketing schließt die Lücke zwischen Vertrieb und Marketing. Dein Vertriebsteam kennt die Kontakte, dein Marketing-Team hat die Kampagnen – durch die Integration arbeiten beide mit denselben Daten.

Kontaktlisten synchronisieren

Die Basis: Kontakte aus Salesforce automatisch in die richtige E-Mail-Liste in Mailchimp oder ActiveCampaign übertragen. Dabei geht es nicht um eine simple 1:1-Kopie, sondern um intelligentes Mapping. Ein Lead in Salesforce mit Status "Marketing Qualified" kommt in die Nurturing-Liste, ein Kunde mit Status "Active" in die Customer-Newsletter-Liste, ein Kontakt mit Opt-out in keine Liste.

Für Mailchimp gibt es eine native AppExchange-Integration, die für viele KMU ausreicht. Für ActiveCampaign oder komplexere Szenarien empfehle ich eine Middleware-Lösung über Make oder Zapier, die mehr Flexibilität beim Mapping bietet.

Kampagnen-Response ins CRM zurückschreiben

Mindestens so wichtig wie die Synchronisation der Kontakte ist die Rückspielung der Kampagnen-Daten ins CRM. Wenn dein Vertriebsteam in Salesforce sehen kann, welche E-Mails ein Lead geöffnet hat, auf welche Links er geklickt hat und an welchen Webinaren er teilgenommen hat, hat es einen enormen Informationsvorsprung im Vertriebsgespräch.

In Salesforce bildet man das typischerweise über Campaign Members ab: Jede E-Mail-Kampagne wird als Salesforce Campaign angelegt, und die Teilnehmer werden als Campaign Members mit dem entsprechenden Status (Sent, Opened, Clicked, Bounced) eingetragen. So hat der Vertriebsmitarbeiter auf dem Kontakt-Record eine vollständige Marketing-Historie.

Segmentierung basierend auf CRM-Daten

Die fortgeschrittene Variante: Du nutzt CRM-Daten für die Segmentierung deiner E-Mail-Kampagnen. Statt im E-Mail-Tool manuell Segmente zu bauen, definierst du die Segmente in Salesforce – basierend auf Daten, die nur dort existieren: Opportunity-Stage, Produktinteresse, Account-Branche, Lead Score. Diese Segmente synchronisierst du als Listen ins E-Mail-Tool und hast damit deutlich präzisere Zielgruppen als mit den limitierten Segmentierungsmöglichkeiten der E-Mail-Plattform allein.

Praxisbeispiel 3: Salesforce + Projektmanagement (Jira/Asana)

Die Übergabe vom Vertrieb an die Delivery ist ein notorischer Schwachpunkt in vielen Unternehmen. Informationen gehen verloren, Projekte starten verzögert, Kunden müssen Dinge wiederholen, die sie dem Vertrieb längst erzählt haben. Eine Integration zwischen CRM und Projektmanagement löst dieses Problem.

Opportunity gewonnen – Projekt automatisch erstellen

Der klassische Trigger: Eine Opportunity wechselt auf "Closed Won", und automatisch wird ein neues Projekt in Jira oder Asana erstellt. Aber es geht um mehr als nur das Anlegen eines leeren Projekts. Die Integration sollte relevante Daten aus der Opportunity in das Projekt übernehmen: Kundenname, Ansprechpartner, Projektumfang (aus der Opportunity-Beschreibung), Budget, geplantes Startdatum und die Custom Fields, die du für dein spezifisches Business definiert hast.

Bei Jira funktioniert das gut über die Jira REST API in Kombination mit einem Salesforce Flow oder einer Middleware. Der Flow triggert auf die Stage-Änderung, sammelt die relevanten Daten und erstellt über die API ein Jira-Issue (oder ein Jira-Projekt, je nach Setup). Bei Asana ist der Ablauf analog – die Asana API ist gut dokumentiert und einfach anzusprechen.

Status-Updates bidirektional synchronisieren

Die wirklich wertvolle Integration geht über die initiale Projekterstellung hinaus: bidirektionale Status-Synchronisation. Wenn das Projektteam in Jira den Status eines Projekts auf "In Progress" oder "Completed" setzt, soll diese Information automatisch im Salesforce-Account sichtbar sein – etwa als Custom Field "Delivery Status" oder als Activity im Activity Feed.

Umgekehrt: Wenn der Vertriebsmitarbeiter in Salesforce eine neue Anforderung des Kunden erfasst (z.B. als Task oder als Update auf der Opportunity), soll diese als Ticket oder Kommentar im Jira-Projekt erscheinen. So bleiben beide Teams synchron, ohne dass jemand manuell Informationen hin- und herkopieren muss.

Middleware-Plattformen im Vergleich

Für die meisten KMU sind Middleware-Plattformen der Sweet Spot zwischen Flexibilität und Aufwand. Hier ein Vergleich der vier relevantesten Optionen:

MuleSoft (Salesforce-eigene iPaaS)

MuleSoft gehört zu Salesforce und ist die Enterprise-Grade Integrationsplattform im Salesforce-Ökosystem. Sie bietet die tiefste native Integration mit Salesforce, umfangreiche Konnektoren für Enterprise-Systeme (SAP, Oracle, etc.) und leistungsstarke Datentransformations-Funktionen. Der Nachteil: MuleSoft ist teuer – typischerweise ab 30.000 Euro pro Jahr – und komplex. Für die meisten KMU ist MuleSoft Overkill, aber wenn du Enterprise-Systeme integrieren musst oder extrem hohe Datenvolumen hast, ist es die beste Wahl im Salesforce-Universum.

Zapier – einfach, schnell, limitiert

Zapier ist der Einstiegsfavorit: intuitive Oberfläche, riesiger Katalog an Konnektoren (über 6.000 Apps), schnelles Setup. Du brauchst kein technisches Wissen, um einen "Zap" zu erstellen. Für einfache Punkt-zu-Punkt-Integrationen – "Wenn X in Salesforce passiert, mache Y in Tool Z" – ist Zapier ideal. Die Grenzen zeigen sich bei komplexeren Szenarien: Multi-Step-Workflows werden unübersichtlich, Datentramsformationen sind limitiert, und bei hohem Volumen wird Zapier schnell teuer (ab ca. 70 Euro/Monat für ernsthaftes Arbeiten).

Make/Integromat – flexibler, günstiger

Make (ehemals Integromat) ist mein persönlicher Favorit für KMU-Integrationen. Die visuelle Workflow-Oberfläche ist leistungsfähiger als Zapier: Du kannst Verzweigungen, Schleifen, Error Handler und komplexe Datentransformationen bauen. Die Salesforce-Module sind umfangreich und unterstützen alle relevanten APIs. Dabei ist Make deutlich günstiger als Zapier – vergleichbare Szenarien kosten oft nur die Hälfte. Die Lernkurve ist etwas steiler als bei Zapier, aber die Investition lohnt sich, sobald deine Integrationen über simple Trigger-Action-Ketten hinausgehen.

Workato – Enterprise-Grade

Workato positioniert sich zwischen Zapier/Make und MuleSoft: leistungsfähiger als die Low-Code-Tools, aber zugänglicher als MuleSoft. Stärken sind das Recipe-Konzept (wiederverwendbare Integrationsbausteine), starke Error-Handling-Mechanismen und gute Governance-Features für größere Teams. Preislich liegt Workato im mittleren Bereich – typischerweise ab 10.000 Euro pro Jahr. Für KMU mit 50+ Mitarbeitern und einer wachsenden Anzahl von Integrationen kann Workato der richtige Schritt zwischen Make und MuleSoft sein.

Best Practices für Integrationen

Unabhängig davon, welchen Ansatz und welche Tools du wählst – diese Best Practices helfen dir, robuste und wartbare Integrationen zu bauen.

Datenmodell vor Integration definieren

Bevor du die erste Integration baust, definiere dein Datenmodell. Welche Felder in Salesforce entsprechen welchen Feldern im Zielsystem? Wie werden Datentypen gemappt (ein Picklist-Wert in Salesforce ist vielleicht ein String in der Buchhaltung)? Was ist das führende System für welche Daten? Dokumentiere diese Entscheidungen, bevor du eine Zeile konfigurierst oder eine Zeile Code schreibst. Diese Arbeit ist nicht glamourös, aber sie verhindert 80 Prozent der Probleme, die in der Praxis auftreten.

Error Handling und Monitoring

Integrationen scheitern. APIs sind nicht erreichbar, Daten haben unerwartete Formate, Limits werden überschritten. Das ist normal und kein Zeichen schlechter Arbeit. Aber du brauchst Mechanismen, die Fehler erkennen, protokollieren und melden. Definiere für jede Integration: Was passiert, wenn ein API-Call fehlschlägt? Wird er automatisch wiederholt (Retry-Logik)? Wird ein Admin benachrichtigt? Werden die fehlgeschlagenen Datensätze in eine Warteschlange geschrieben? In Middleware-Plattformen wie Make gibt es eingebaute Error Handler – nutze sie konsequent.

Idempotenz sicherstellen

Idempotenz bedeutet: Wenn eine Operation mehrfach ausgeführt wird, ist das Ergebnis dasselbe wie bei einmaliger Ausführung. Für Integrationen ist das essenziell. Stell dir vor, deine Integration erstellt einen Kontakt in der Buchhaltung, wenn ein Account in Salesforce angelegt wird. Was passiert, wenn die Integration zweimal triggert (z.B. wegen eines Retry nach Timeout)? Ohne Idempotenz hast du jetzt einen Duplikat-Kontakt in der Buchhaltung.

Die Lösung: Verwende eindeutige Identifikatoren (z.B. die Salesforce Record ID) und prüfe vor dem Erstellen, ob der Datensatz bereits existiert. Bei Updates ist Idempotenz einfacher – ein Update mit denselben Daten mehrfach auszuführen ist harmlos. Bei Creates brauchst du die explizite Prüfung.

Dokumentation pflegen

Jede Integration sollte dokumentiert sein: Welche Systeme sind verbunden? Welche Daten fließen in welche Richtung? Welche Trigger lösen die Synchronisation aus? Welche Credentials werden verwendet? Wo werden Fehler protokolliert? Diese Dokumentation muss nicht umfangreich sein – eine Seite pro Integration reicht. Aber sie muss existieren und aktuell gehalten werden. Wenn du in sechs Monaten (oder dein Nachfolger in zwei Jahren) ein Problem mit einer Integration debuggen musst, wirst du dankbar sein.