Salesforce ERP Sync-Probleme: Ursachen und Lösungen

Ein Auftrag ist in Salesforce bestätigt, fehlt aber im ERP. Bevor Sie die Integration neu bauen, verfolgen Sie diesen Datensatz: Wo wurde er zuletzt angenommen, welche Antwort kam zurück und wer kann ihn wiederherstellen?

Dieser Leitfaden dient als Ausgangspunkt für die Diagnose. Die folgenden Szenarien veranschaulichen Fehlerbilder; sie sind keine Kundenfallstudien oder gemessenen Ergebnisse.

Drei Fehlerbilder für die Diagnose

Prüfen Sie zunächst, welches dieser Fehlerbilder auf die betroffenen Datensätze zutrifft:

• Stille Ausfälle: Daten hören auf zu synchronisieren, aber niemand bemerkt es, bis ein Kunde wegen einer fehlenden Bestellung anruft
• Kaskadenfehler: Eine fehlgeschlagene Transaktion blockiert alles dahinter und erzeugt einen Rückstau von 100+ fehlgeschlagenen Syncs
• Das Vendor-Update: Ihr ERP-Anbieter schiebt ein Update, das einen Feldnamen ändert, und plötzlich funktioniert nichts mehr

Ein temporärer Patch kann den Datenfluss wiederherstellen, ohne die Ursache zu erklären. Bewahren Sie die ursprüngliche Fehlermeldung und die Datensatz-IDs für die Untersuchung auf.

Ihr Operations-Team passt sich an, indem es "Backup-Prozesse" aufbaut — Tabellenkalkulationen, manuelle Prüfungen, wöchentliche Abstimmungsmeetings. Die Integration wird zum Problem, das sie eigentlich lösen sollte.

Warum das passiert (Es liegt nicht an den Tools)

Das Problem ist nicht Salesforce. Es ist nicht Ihr ERP. Die Middleware-Plattform, die Sie gewählt haben, ist wahrscheinlich in Ordnung.

Ein Prüfbereich ist die Architektur: drei Annahmen, die während des Verkaufsprozesses vernünftig erscheinen, aber unter realen Bedingungen versagen:

Annahme 1: "Echtzeit-Sync ist immer besser"

Echtzeit-Synchronisierung klingt ideal. Angebot in Salesforce erstellt? Erscheint sofort im ERP. Perfekt, oder?

Bis Ihr ERP für 15 Minuten während eines geplanten Wartungsfensters nicht verfügbar ist. Oder ein Netzwerkproblem einen Timeout verursacht. Oder jemand einen unvollständigen Datensatz speichert. Echtzeit-Sync bedeutet Echtzeit-Ausfälle.

Beispielszenario: Das ERP ist während der Wartung nicht verfügbar. Ohne dauerhafte Speicherung und Wiederherstellungsweg kann ein Auftrag auch danach im ERP fehlen.

Annahme 2: "Die Integration erledigt alles automatisch"

Die meisten Integrationen sind für den Happy Path gebaut. Kunde existiert in beiden Systemen? Grossartig. Standardprodukt? Kein Problem. Preisliste stimmt überein? Perfekt.

Aber was passiert, wenn:

• Ein neuer Kunde in Salesforce existiert, aber noch nicht im ERP?
• Eine Sonderpreisvereinbarung für dieses Angebot gilt?
• Das Produkt verfügbar ist, aber eine kundenspezifische Konfiguration benötigt?

Ohne explizite Fehlerbehandlung für Grenzfälle scheitert die Integration still oder, schlimmer, erzeugt fehlerhafte Daten. Sie entdecken das Problem, wenn die Buchhaltung den Monat abgleicht und Unstimmigkeiten findet.

Annahme 3: "Sobald es funktioniert, funktioniert es weiter"

Integrationsprojekte haben eine Testphase. Alles besteht. Sie gehen live. Erfolg.

Dann aktualisiert Ihr ERP-Anbieter auf Version 12.3. Ein Feldname ändert sich. Ein Datentyp wechselt von String zu Integer. Ein API-Endpunkt wird deprecated.

Die Integration bricht zusammen. Und weil niemand dokumentiert hat, welche Felder, Endpunkte oder Transformationen die Integration tatsächlich verwendet, dauert die Behebung Tage der Untersuchung.

Salesforce Architecture: Integration Patterns

---

Die Architektur, die tatsächlich funktioniert

Diese Architekturentscheidungen können die Wiederherstellung nach Fehlern erleichtern:

Prinzip 1: Design für Ausfälle

Gehen Sie davon aus, dass Ausfälle passieren werden. Bauen Sie explizit dafür:

• Dauerhafte Warteschlangen nutzen, wenn asynchrone Verarbeitung zum Ablauf passt: Wenn ein Datensatz synchronisiert werden muss, stellen Sie ihn in eine Warteschlange. Verarbeiten Sie die Warteschlange mit Retry-Logik. Wenn etwas fehlschlägt, blockiert es nicht alles andere.
• Implementieren Sie exponentielles Backoff: Vergrössern Sie den Abstand zwischen Wiederholungen, begrenzen Sie die Versuche und beachten Sie API-Limits. Verhindern Sie Duplikate bei wiederholten Anfragen.
• Alarmieren Sie bei Mustern, nicht bei einzelnen Ausfällen: Ein fehlgeschlagener Sync? Normal. Zehn Ausfälle in einer Stunde? Jemanden alarmieren.

Wiederholungsversuche helfen bei vorübergehenden Unterbrechungen. Fehlende Kunden, ungültige Werte oder Berechtigungsfehler erfordern eine andere Reaktion: zuerst die Ursache beheben, dann die Anfrage erneut verarbeiten.

Prinzip 2: Machen Sie Ausfälle sichtbar

Die schlimmsten Ausfälle sind die stillen. Design für Sichtbarkeit:

• Fehler-Dashboards: Zeigen Sie, was fehlgeschlagen ist, warum, und was Aufmerksamkeit braucht
• Wöchentliche Zusammenfassungsberichte: Erfassen Sie erfolgreiche Datensätze, Wiederholungsversuche und offene manuelle Prüfungen getrennt.
• Klare Eigentümerschaft: Jemand muss die Integrationsgesundheit besitzen (normalerweise Operations, nicht IT)

Sie können Probleme nicht beheben, von denen Sie nicht wissen. Sichtbarkeit ist nicht optional.

Prinzip 3: Dokumentieren Sie Abhängigkeiten

Wenn Ihre Integration bricht (und das wird sie), müssen Sie wissen:

• Welche API-Endpunkte sie verwendet
• Welche Felder obligatorisch vs. optional sind
• Welche Datentransformationen stattfinden
• Welches System die Wahrheitsquelle für jeden Datentyp ist

Diese Dokumentation ist nicht für Ihr aktuelles Selbst. Sie ist für Ihr Team in sechs Monaten, wenn etwas am Freitag um 16 Uhr bricht und Sie verstehen müssen, was sich geändert hat.

Eine fehlerhafte Salesforce-Integration untersuchen

1. Wählen Sie einen betroffenen Auftrag und erfassen Sie seine ID in beiden Systemen. Vergleichen Sie ihn mit einem erfolgreichen Auftrag.
2. Suchen Sie die letzte erfolgreiche Übergabe. Prüfen Sie Zeitstempel, Antwortcodes und Integrationsprotokolle.
3. Prüfen Sie Authentifizierung, Pflichtfelder, Feldzuordnungen sowie kürzliche API- oder Konfigurationsänderungen.
4. Prüfen Sie vor einer Wiederholung, ob der Auftrag im Zielsystem bereits existiert. Eine stabile externe ID hilft, Duplikate zu vermeiden.
5. Testen Sie die Korrektur mit einer kontrollierten Auswahl. Gleichen Sie danach betroffene Datensätze ab und dokumentieren Sie die Wiederherstellung.

Klären Sie, welches System welches Feld führt, welche Verzögerungen akzeptabel sind und wer nicht automatisch behebbare Fehler bearbeitet. Der passende Entwurf hängt vom Ablauf ab.

Fragen an Ihren Integrationsanbieter

Vor Ihrem nächsten Integrationsprojekt (oder bei der Bewertung Ihres aktuellen), fragen Sie:

1. Was passiert, wenn das ERP vorübergehend nicht verfügbar ist? Wenn die Antwort "der Sync wird fehlschlagen" ist, fragen Sie nach Retry-Mechanismen.
2. Wie wissen wir, wenn etwas bricht? Wenn die Antwort "Sie werden Fehler sehen" ist, fragen Sie nach Monitoring- und Alerting-Details.
3. Wem gehört die Dokumentation? Wenn die Antwort unklar ist oder "wir liefern Dokumentation", stellen Sie sicher, dass Sie tatsächlich brauchbare Dokumentation bekommen, nicht nur API-Spezifikationen.
4. Was ist der Disaster-Recovery-Prozess? Wenn etwas am Freitag um 18 Uhr bricht, was passiert? Gibt es eine Warteschlange, die wir erneut abspielen können? Oder verlieren wir Daten?
5. Kann unser Team das selbst ändern? Vendor Lock-in geht nicht um die Software. Es geht um Wissens-Lock-in.