# ServiceNow Salesforce Schnittstelle

*ServiceNow → Salesforce*

**Kurz gesagt:** Eine ServiceNow-Salesforce-Anbindung sorgt dafür, dass Servicedesk und CRM denselben Kunden beschreiben. Sie bildet ServiceNow-Incidents und CSM-Cases auf Salesforce-Cases ab, gleicht Accounts und Kontakte über eine stabile externe ID statt über den Namen ab und übersetzt ServiceNow-Auswahlwerte (State, Priorität, Zuweisungsgruppe) in Salesforce-Auswahllisten und Verantwortliche. Richtig gemacht ist das kein nächtlicher CSV-Lauf und keine brüchige Punkt-zu-Punkt-Verbindung, sondern eine idempotente, delta-basierte Pipeline mit Schleifenschutz - so sieht der Account-Verantwortliche in Salesforce die reale Support-Lage, ohne dass ein System das andere überschreibt.

## Was eine ServiceNow-Salesforce-Anbindung wirklich leistet

ServiceNow kennt die operative Wahrheit über einen Kunden: den offenen P1-Incident, den CSM-Case, der auf ein Ersatzteil wartet, das um 14:00 gerissene SLA, den für das Wochenende geplanten Change. Salesforce kennt die kaufmännische Wahrheit: wem der Account gehört, was er zahlt, die Verlängerung in neunzig Tagen, die offene Opportunity, die der Support-Rückstand still gefährdet.

Diese beiden Wahrheiten liegen in getrennten Systemen unter getrennten Teams, und die Lücke dazwischen ist teuer. Der Account-Verantwortliche in Salesforce ruft einen Kunden an, der in ServiceNow drei eskalierte Incidents offen hat. Der Support-Agent in ServiceNow schließt einen Case für einen Account, den der Vertrieb vergangene Woche als abwanderungsgefährdet markiert hat - erfahren hat er es nie.

Eine ServiceNow-Salesforce-Anbindung schließt diese Lücke. Sie bildet jeden relevanten ServiceNow-Datensatz und Statuswechsel auf das richtige Salesforce-Objekt ab, gleicht die gemeinsamen Accounts und Kontakte ab und hält beide Seiten aktuell - so sieht die Person, die den Kunden in einem der Systeme öffnet, dieselbe Realität.

## Welche Daten fließen

| Objekt / Ereignis in ServiceNow | Wird in Salesforce zu | Hinweis |
| --- | --- | --- |
| Incident (`incident`) | Case | State und Priorität in Salesforce-Auswahllisten übersetzt |
| CSM-Case (`sn_customerservice_case`) | Case | Kanal, Kontakt und Produkt durchgereicht |
| Account (`customer_account`) | Account | Über externe ID korreliert, nicht über den Namen |
| Kontakt / Benutzer (`customer_contact`, `sys_user`) | Contact | Über E-Mail plus stabile ID abgeglichen und entdoppelt |
| Zuweisungsgruppe | Case-Owner / Queue | Gruppe-zu-Queue-Mapping einmal abgestimmt, dann durchgesetzt |
| SLA-Verletzung (`task_sla`) | Case-Kennzeichen / Feld | Macht gefährdete Accounts für den Verantwortlichen sichtbar |
| Arbeitsnotizen & Kommentare | Case-Kommentar / Feed-Eintrag | Nur öffentliche Kommentare; interne Arbeitsnotizen bleiben intern |
| Status gelöst / geschlossen | Case-Status geschlossen | Schließungscode und Lösungshinweis mit übertragen |
| CMDB-CI (`cmdb_ci`) | Asset | Optional, wo Entitlement oder Installationsbasis relevant ist |

Das genaue Objekt-Mapping, die Feld-für-Feld-Hoheit und die Übersetzung von Auswahllisten und Gruppen stimmen wir einmalig im Scoping ab und hinterlegen sie in der Pipeline. Danach mappt sie niemand mehr von Hand.

## Die Details, an denen einfache Syncs scheitern

Eine Punkt-zu-Punkt-Verbindung oder ein generischer Connector liefert Ihnen eine Demo und lässt die teuren Sonderfälle auf Ihrem Schreibtisch liegen:

- **ID-Abgleich.** Eine ServiceNow-`sys_id` ist eine 32-stellige GUID, eine Salesforce-`Id` ist 18-stellig. Ein Abgleich über Firmenname oder E-Mail erzeugt Dubletten, sobald jemand einen Account umbenennt oder ein Kontakt den Job wechselt. Die Korrelation muss über eine gespeicherte externe ID auf beiden Seiten laufen, und jeder Schreibvorgang muss ein Upsert dagegen sein.
- **Auswahlwerte sind keine Strings.** ServiceNow speichert den Incident-`state` als Ganzzahl (1 Neu, 2 In Bearbeitung, 6 Gelöst, 7 Geschlossen) und die Priorität 1-5 mit 1 als Kritisch. Der Salesforce-Case nutzt Auswahllisten-Strings und Hoch / Mittel / Niedrig. Jeder Wert braucht eine explizite, abgestimmte Übersetzung - und sie muss laut scheitern, sobald jemand einen neuen ServiceNow-Wert anlegt, den niemand gemappt hat.
- **Update-Schleifen.** Spielen Sie eine Änderung aus ServiceNow nach Salesforce, kann das resultierende Salesforce-Update im bidirektionalen Betrieb direkt zurückspringen und ServiceNow erneut auslösen. Ohne Prüfung des zuletzt ändernden Benutzers und eines Change-Tokens wird aus einer menschlichen Bearbeitung ein endloses Echo.
- **Delta statt Vollscan.** Bei jedem Lauf jeden Incident und Account neu zu lesen, verbrennt API-Budget und kollidiert mit laufenden Bearbeitungen. Ein `sys_updated_on`-Wasserstand auf der ServiceNow-Seite und `SystemModstamp` auf der Salesforce-Seite begrenzen den Sync auf das tatsächlich Geänderte - und Löschungen brauchen eine eigene Behandlung, denn ServiceNow meldet keine Löschung, solange die Tabelle nicht auditiert ist, und Salesforce erfordert eine explizite getDeleted-Abfrage.
- **Teilweise Fehler.** Ein Batch aus fünfzig Case-Updates, bei dem drei an einer Salesforce-Validierungsregel oder einem Pflichtfeld scheitern, darf die anderen siebenundvierzig nicht mitreißen. Fehlerhafte Datensätze wandern mit Begründung in eine Dead-Letter-Queue, werden erneut versucht und als Alert sichtbar - sie verschwinden nicht still.
- **Kommentare und Sichtbarkeit.** ServiceNow-Arbeitsnotizen sind intern, kundenseitige Kommentare nicht. Synchronisiert man das falsche Journalfeld, landen interne Engineering-Notizen auf einem kundensichtbaren Salesforce-Case. Die Grenze zwischen öffentlich und intern muss im Mapping explizit sein.

## Wie wir sie bauen und betreiben

Wir behandeln das als Pipeline, nicht als einmaligen Flow. ServiceNow-Datensätze werden zeitgesteuert (oder per Business-Rule-Outbound-Webhook) gegen die Table-API gelesen, per Wasserstand gefiltert, validiert, in Ihr abgestimmtes Salesforce-Mapping überführt und über die Salesforce-Composite- und Bulk-API geschrieben, um innerhalb der Governor- und Tageslimits zu bleiben.

Die Pipeline ist idempotent: Jeder Datensatz trägt eine stabile Korrelations-ID, und jeder Schreibvorgang ist ein Upsert, sodass ein erneuter Lauf oder ein vollständiger Re-Sync nie einen doppelten Case, Account oder Contact erzeugt. Der Schleifenschutz ist eingebaut, damit sich die bidirektionale Synchronisation nicht in den eigenen Schwanz beißt. Sie läuft auf cloud-nativer, vollständig EU-gehosteter AWS-Infrastruktur - Kunden- und Kontaktdaten verlassen die EU nicht, was AVV und DSGVO sauber hält.

Und dann halten wir sie am Laufen. Monitoring, Alerting, Incident Response und - entscheidend - das Beobachten abgekündigter Salesforce-API-Versionen sowie von ServiceNow-Plattform-Upgrades und Konfigurationsänderungen liegen vertraglich bei uns. Wird eine Zuweisungsgruppe umbenannt oder erhält eine Auswahlliste einen neuen Wert, fangen wir das ab, bevor es den Sync bricht. Sie bekommen einen festen Ansprechpartner und ein SLA statt eines Flows, der nach dem nächsten Release still aufhört, Datensätze abzugleichen.

## Wann sich diese Anbindung lohnt

Wenn sich eine Handvoll Accounts überschneidet und jemand morgens in beide Systeme schauen kann, brauchen Sie keine Pipeline - und das sagen wir Ihnen auch. Ein einzelnes Dashboard oder ein manueller Wochenexport reicht in dieser Größenordnung völlig.

Die Anbindung lohnt sich, wenn Support-Volumen und Account-Zahl steigen, wenn Vertrieb und Support wiederholt auf veraltete Informationen über denselben Kunden reagieren, wenn Account- und Kontakt-Dubletten Ihr CRM zu verschmutzen beginnen, oder wenn ein intern gebauter bidirektionaler Sync zur Quelle von Schleifen, Dubletten und stillen Fehlern geworden ist, die niemand verantwortet. Dann kostet eine betreute, EU-gehostete Pipeline mit festem Ansprechpartner weniger als die Abwanderung und die Nacharbeit, die sie verhindert.

## Häufig gestellte Fragen

### Muss ServiceNow oder Salesforce das führende System sein?

Meist beide - je nach Objekt. Salesforce führt Accounts, Kontakte und die Geschäftsbeziehung; ServiceNow führt Incidents, Servicefälle und die CMDB. Es geht nicht darum, ein System zum Master zu krönen, sondern darum, pro Feld festzulegen, wer gewinnt, und das durchzusetzen. So überschreibt ein Support-Agent, der in ServiceNow einen Case bearbeitet, nie unbemerkt die Änderung eines Account-Verantwortlichen in Salesforce. Diese Richtung legen wir im Scoping Feld für Feld fest.

### Wie gleichen Sie Datensätze ab, ohne Dubletten zu erzeugen?

Nicht über den Firmennamen oder die E-Mail-Adresse - die driften und kollidieren. Wir korrelieren über stabile Kennungen: Die ServiceNow-sys_id wird in ein Salesforce-External-ID-Feld geschrieben, die 18-stellige Salesforce-Id zurück in die ServiceNow-correlation_id. Jeder Schreibvorgang ist ein Upsert auf diese externe ID, sodass ein erneuter Lauf den bestehenden Datensatz aktualisiert, statt einen zweiten anzulegen.

### Kann die Schnittstelle bidirektional laufen, ohne Update-Schleifen zu erzeugen?

Ja, und der Schleifenschutz ist genau der Teil, den einfache Aufsätze falsch machen. Ein aus ServiceNow nach Salesforce gespieltes Update darf nicht zurückspringen und erneut einen ServiceNow-Schreibvorgang auslösen. Wir markieren von der Integration ausgelöste Änderungen und prüfen den zuletzt ändernden Benutzer sowie ein Change-Token, bevor wir weiterleiten. So führt eine Bearbeitung zu genau einem Schreibvorgang auf der Gegenseite, nicht zu einem endlosen Echo.

### Was ist mit Salesforce-API-Limits und ServiceNow-Drosselung bei Volumen?

Wir arbeiten in Batches. Salesforce-Schreibvorgänge laufen über die Composite- und Bulk-API und bleiben so deutlich innerhalb der Tages- und Governor-Limits; ServiceNow-Lesevorgänge sind gegen die Table-API paginiert und nutzen einen sys_updated_on-Wasserstand, sodass wir nur Geändertes abholen. Drosselt eine Instanz oder fällt ein Wartungsfenster an, wartet die Pipeline ab und setzt am letzten Wasserstand wieder auf, statt Datensätze zu verlieren.

### Wer betreibt die Schnittstelle nach dem Go-live?

Wir. Die Pipeline läuft auf cloud-nativer, vollständig EU-gehosteter Infrastruktur, die wir überwachen. Wenn Salesforce eine API-Version abkündigt oder Ihr Team eine ServiceNow-Zuweisungsgruppe oder Auswahlliste umbaut, ist das unser Problem - keine kaputte Synchronisation, die Support und Vertrieb mitten in der Schicht entdecken. Sie bekommen einen festen Ansprechpartner, Alerting und ein SLA statt eines Flows, den jemand gebaut und liegen gelassen hat.

## Verwandte Integrationen

- [Intercom ↔ Salesforce](https://seamless.engineering/de/integrations/intercom-salesforce/): Intercom Salesforce Schnittstelle
- [Salesforce ↔ Jira](https://seamless.engineering/de/integrations/salesforce-jira/): Salesforce Jira Schnittstelle
- [ServiceNow ↔ Jira](https://seamless.engineering/de/integrations/servicenow-jira/): ServiceNow Jira Schnittstelle
- [Zendesk ↔ Salesforce](https://seamless.engineering/de/integrations/zendesk-salesforce/): Zendesk Salesforce Schnittstelle
- [Airtable ↔ Salesforce](https://seamless.engineering/de/integrations/airtable-salesforce/): Airtable Salesforce Schnittstelle
- [Dynamics 365 ↔ Salesforce](https://seamless.engineering/de/integrations/dynamics-365-salesforce/): Dynamics 365 Salesforce Schnittstelle

## Nach System

- [Alle Schnittstellen für ServiceNow](https://seamless.engineering/de/integrations/servicenow/)
- [Alle Schnittstellen für Salesforce](https://seamless.engineering/de/integrations/salesforce/)
- [Salesforce API-Changelog](https://seamless.engineering/de/api-changelog/salesforce/): Keine Breaking Changes oder Deprecations in den letzten 90 Tagen

## Scoping-Gespräch anfragen

Sie möchten diese Integration umsetzen und dauerhaft betreiben lassen? Sagen Sie uns, welche Systeme verbunden werden sollen und welche Daten fließen müssen. Festpreis-Angebot zur Aufwandsabschätzung innerhalb von 48 Stunden.

- E-Mail: hello@seamless.engineering
- Kontaktformular: https://seamless.engineering/de/#contact