In welche Richtung fließen die Daten, und geht auch beides?

Der primäre Fluss geht von SmartRecruiters nach SAP SuccessFactors: Ein eingestellter Kandidat wird zum Neueintritt in Employee Central oder zum Onboardee im Onboarding 2.0. Viele Kunden wollen zusätzlich die Gegenrichtung - freigegebene Anforderungen und Planstellen fließen aus SuccessFactors nach SmartRecruiters, damit Recruiter Stellendaten nicht abtippen. Wir bauen die Richtungen, die Sie brauchen, und halten sie konsistent.

Schreiben Sie direkt in Employee Central oder ins Onboarding 2.0?

Beides sind valide Ziele, sie verhalten sich aber unterschiedlich. Employee Central erwartet einen zeitraumbezogenen Neueintritt aus zusammengesetzten Entitäten wie PerPerson, EmpEmployment und EmpJob. Onboarding 2.0 erwartet einen Onboardee, der später zum EC-Mitarbeiter konvertiert wird. Das Ziel stimmen wir vorab mit Ihrer HR-IT ab, weil es beeinflusst, wie Identität, Eintrittsdatum-Änderungen und Wiedereintritte behandelt werden.

Wie verhindern Sie, dass ein Wiedereintritt eine doppelte Person anlegt?

SuccessFactors identifiziert Personen über eine stabile Kennung (person-id-external), und ein Wiedereintritt muss an die bestehende Person andocken, statt eine neue anzulegen. Wir gleichen eingehende Einstellungen anhand der von Ihnen festgelegten Kennungen mit bestehenden Datensätzen ab - Personalnummer, Ausweis, E-Mail oder eine frühere Personen-ID - und leiten bestätigte Wiedereintritte in einen Aktualisierungsfluss statt in einen Neuanlage. Das ist der häufigste Fehler naiver Exporte.

Was passiert, wenn sich das Eintrittsdatum ändert, nachdem wir den Eintritt schon exportiert haben?

Die Pipeline behandelt den Export als Aktualisierung, nicht als einmalige Neuanlage. Weil jede SmartRecruiters-Einstellung eine stabile Kennung trägt, erzeugt ein geändertes Eintrittsdatum, ein neuer Titel oder ein neuer Standort einen korrigierten zeitraumbezogenen Datensatz in SuccessFactors und keinen zweiten Mitarbeiter. Späte Angebotsänderungen sind im Recruiting normal, und die Schnittstelle rechnet damit.

Sind die Kandidatendaten DSGVO-konform, und wie halten Sie es mit dem Betriebsrat?

Die Pipeline läuft auf cloud-nativer, vollständig EU-gehosteter Infrastruktur, sodass Kandidaten- und Mitarbeiterdaten die EU nicht verlassen. Wir arbeiten unter einem AVV und legen genau fest, welche Felder wann die Grenze zwischen den Systemen überschreiten. Das ist entscheidend, wenn der Betriebsrat freigeben muss, welche Recruiting-Daten im führenden HR-System landen. Der Datenfluss ist dokumentiert und nicht in einem Plugin versteckt.

SmartRecruiters SAP SuccessFactors Schnittstelle

Was eine Anbindung von SmartRecruiters an SAP SuccessFactors wirklich leistet

SmartRecruiters weiß alles darüber, wie jemand eingestellt wurde - auf welche Anforderung er sich beworben hat, welches Angebot freigegeben wurde, das Eintrittsdatum, den Standort, den Lebenslauf, den unterschriebenen Arbeitsvertrag. SAP SuccessFactors braucht dieselbe Person als strukturierten Mitarbeiterdatensatz: der richtigen juristischen Person, Planstelle und Kostenstelle zugeordnet, mit gültigem Eintrittsdatum und jedem Feld auf einen Code gemappt, den das HR-System tatsächlich kennt.

Zwischen “Kandidat auf eingestellt gesetzt” und “Mitarbeiter aktiv in Employee Central” liegt heute die Handarbeit - HR tippt Namen, Eintrittsdaten und Organisationszuordnungen von einer Maske in die nächste und jagt anschließend den Fehlern hinterher. Eine Anbindung von SmartRecruiters an SAP SuccessFactors schließt diese Lücke: Sie liest den Einstellungsvorgang, wendet Ihr Mapping an und legt Neueintritt oder Onboardee sauber an. In der Gegenrichtung versorgt sie SmartRecruiters mit freigegebenen Anforderungen und Planstellen, damit Recruiter Stellen gegen echte SuccessFactors-Daten öffnen statt gegen Freitext.

Welche Daten fließen

Objekt / Vorgang in SmartRecruiters	Wird in SAP SuccessFactors zu	Hinweis
Kandidat erreicht Status eingestellt	Neueintritt in Employee Central oder Onboardee im Onboarding 2.0	Auslöser des gesamten Flusses; Schlüssel aus Kandidat + Bewerbung
Persönliche Daten (Name, Geburtsdatum, E-Mail, Telefon, Adresse)	PerPerson, PerPersonal, PerEmail, PerPhone, PerAddressDEFLT	Zeitraumbezogen zum Eintrittsdatum; länderspezifischer Adressblock für DE/AT/CH
Angebot (Eintrittsdatum, Stellenbezeichnung, Vergütung)	EmpEmployment, EmpJob, Vergütung über payComponents	Eintrittsdatum ist das gültig-ab jedes zeitraumbezogenen Datensatzes; Vergütung braucht Währung und Frequenz
Planstelle / Abteilung auf der Bewerbung	Position externalCode, Job Classification, Legal Entity, Business Unit, Location	Muss exakt auf die SuccessFactors-Foundation-Object-Codes auflösen, nicht auf Anzeigetexte
Lebenslauf, Angebot, unterschriebene Dokumente	Mitarbeiterdokumente / Onboarding-Anhänge	MIME- und Größenlimits; ein Teil geht ins Onboarding statt nach EC
Freigegebene Anforderung / Planstelle (Gegenrichtung)	Stellenausschreibung in SmartRecruiters	Planstelle, Hiring Manager, Abteilung und Standort zurück ins ATS

Die konkreten Foundation-Object-Codes, Feld-Mappings und das Zielverfahren stimmen wir einmalig mit Ihrer HR-IT ab und hinterlegen sie in der Pipeline. Danach tippt niemand mehr einen Eintritt von Hand ab.

Die Details, an denen einfache Syncs scheitern

Ein Punkt-zu-Punkt-Connector oder ein nächtlicher CSV-Export bringt Sie die einfachen 80 % voran und lässt die teuren 20 % bei HR liegen:

Foundation Objects sind Codes, keine Anzeigetexte. SmartRecruiters führt einen Standort vielleicht als “Büro München”, während SuccessFactors einen Location-externalCode, eine Legal Entity und eine Job Classification erwartet, die exakt auflösen. Ein Beinahe-Treffer setzt den Mitarbeiter stillschweigend in die falsche Organisationseinheit. Das Mapping muss explizit und gegen die Live-Daten aus SuccessFactors validiert sein.
In Employee Central ist alles zeitraumbezogen. Ein Neueintritt ist kein flacher Datensatz, sondern ein Satz zusammengesetzter Entitäten (PerPerson, EmpEmployment, EmpJob), die alle ein gültiges Eintrittsdatum brauchen. Fehlt das gültig-ab, scheitert der OData-Upsert oder wird nur halb angewendet.
Wiedereintritte dürfen keine Dubletten werden. SuccessFactors schlüsselt Personen über person-id-external. Ein zurückkehrender Mitarbeiter muss an die bestehende Person andocken, nicht eine zweite erzeugen. Naive Exporte legen blind an und verunreinigen das führende System.
Angebotsänderungen kommen spät. Eintrittsdaten, Titel und Standorte verschieben sich nach dem Export. Der Eintritt muss als Korrektur gegen denselben Schlüssel erneut gesendet werden, nicht als neuer Mitarbeiter.
Teilfehler sind real. Ein EC-Composite-Upsert kann die Person anlegen und dann bei Beschäftigung oder Planstelle scheitern. Die Pipeline muss den Teilzustand erkennen, sicher erneut versuchen und den bereits erfolgreichen Teil nie doppelt anwenden.
Rate Limits und Delta-Fenster. Die SuccessFactors-OData-API drosselt, und SmartRecruiters-Status-Webhooks können an einem Einstellungstag stoßweise eintreffen. Eine robuste Pipeline taktet ihre Aufrufe, verarbeitet Deltas statt Vollabgleiche und wahrt die Reihenfolge, damit eine Aktualisierung nie die Anlage überholt, von der sie abhängt.

Wie wir sie bauen und betreiben

Wir behandeln das als Pipeline, nicht als nächtlichen Job, den jemand beaufsichtigt. Einstellungsvorgänge aus SmartRecruiters werden per Webhook erfasst oder zeitgesteuert abgeholt, validiert, gegen bestehende SuccessFactors-Personen abgeglichen, in Ihr abgestimmtes EC- oder Onboarding-Payload überführt und über die OData-API geschrieben - die Gegenrichtung für Anforderungen läuft genauso.

Die Pipeline ist idempotent: Jede SmartRecruiters-Einstellung trägt eine stabile Kennung, sodass ein erneuter Versuch, ein erneuter Lauf oder eine späte Angebotsänderung nie einen doppelten Mitarbeiter erzeugt. Sie läuft auf cloud-nativer, vollständig EU-gehosteter Infrastruktur - Kandidaten- und Mitarbeiterdaten verlassen die EU nicht, was AVV, DSGVO und eine etwaige Betriebsvereinbarung sauber und prüfbar hält.

Und dann halten wir sie am Laufen. Monitoring, Alerting, Incident Response und das Beobachten von API-Änderungen bei SmartRecruiters und SuccessFactors liegen vertraglich bei uns, mit festem Ansprechpartner und SLA. Wenn SAP eine neue OData-Version ausliefert oder SmartRecruiters ein Webhook-Payload ändert, ist das unser Problem - gelöst vor Ihrer nächsten Einstellung, keine böse Überraschung, die HR am ersten Arbeitstag entdeckt.

Wann sich diese Anbindung lohnt

Wenn Sie eine Handvoll Menschen im Monat in eine einzige juristische Person einstellen, ist die Erfassung in SuccessFactors von Hand völlig in Ordnung - und wir sagen Ihnen das auch. Die Anbindung lohnt sich, wenn das Einstellungsvolumen steigt, wenn Sie mehrere juristische Personen und Standorte mit strenger Foundation-Object-Governance besetzen, wenn Wiedereintritte und späte Angebotsänderungen die manuelle Erfassung fehleranfällig machen, oder wenn ein fehlerhafter Neueintritt bedeutet, dass jemand am ersten Tag ohne Systemzugang dasteht. Dann ist eine betreute Pipeline günstiger als die Fehler.