HiBob BambooHR Schnittstelle

Was eine HiBob-BambooHR-Anbindung wirklich leistet

HiBob und BambooHR sind beide führende HR-Systeme - und genau deshalb ist ihre Synchronisation schwieriger, als sie aussieht. Wenn sich eine Gruppe in der Zentrale auf HiBob festlegt, eine Tochter oder eine frisch übernommene Gesellschaft aber bei BambooHR bleibt - oder wenn eine Migration beide Systeme einige Monate parallel laufen lässt -, muss jeder Eintritt, Austritt, jede Beförderung und jede Adressänderung in beiden Systemen existieren. Von Hand tippt jemand denselben Vorgang zweimal ab, und die beiden Systeme laufen innerhalb einer Woche auseinander.

Eine HiBob-BambooHR-Anbindung schließt diese Lücke automatisch. Sie macht HiBob zum führenden System, liest jede relevante Änderung, ordnet die Person dem richtigen BambooHR-Datensatz zu und schreibt die korrekten Felder und stichtagsbezogenen Historienzeilen nach BambooHR - ohne dass jemand eine Tabelle darüber pflegt, wer sich wann geändert hat.

Welche Daten fließen

Objekt / Vorgang in HiBob	Wird in BambooHR zu	Hinweis
Person (Neueintritt)	Mitarbeiter-Datensatz	Zuordnung über Arbeits-E-Mail; nur angelegt, wenn kein BambooHR-Datensatz existiert
Personen- und Kontaktfelder	Mitarbeiterfelder	Name, Anschrift, Telefon, private E-Mail, Geburtsdatum je Feld abgebildet
Anstellung / Position	Zeile in Job Information	Stichtagsbezogen: Titel, Abteilung, Bereich, Standort, Anstellungsart
Berichtslinie (Vorgesetzte)	Feld Supervisor	Aufgelöst zur BambooHR-ID der Führungskraft, damit das Orgchart intakt bleibt
Vergütung / Gehalt	Zeile in Compensation	Stichtagsbezogen, mit Währung und Zahlungsrhythmus je Person abgebildet
Lifecycle-Änderung (Austritt)	Beschäftigungsstatus + Austrittsdatum	Statuswert muss einem BambooHR-Listenwert entsprechen
Abwesenheitsantrag (genehmigt)	Time-Off-Antrag	Auf eine existierende BambooHR-Abwesenheitsart abgebildet; Tage vs. Stunden abgeglichen
Benutzerdefinierte Felder / Listen	Benutzerdefinierte Felder	Listenwerte (z. B. Abteilungen, Standorte) müssen in BambooHR bereits existieren

Die konkrete Feldzuordnung, die Listenwerte und die Zuordnung der Abwesenheitsarten stimmen wir einmalig im Scoping ab und hinterlegen sie in der Pipeline. Danach ordnet sie niemand mehr von Hand zu.

Die Details, an denen einfache Syncs scheitern

Ein einmaliger CSV-Upload oder eine generische Connector-App bringt Sie fast ans Ziel und lässt den teuren Teil auf Ihrem Schreibtisch liegen:

• Die ID-Namensräume passen nicht zusammen. Die Personen-ID von HiBob und die numerische Employee-ID von BambooHR haben nichts miteinander zu tun. Die einzige verlässliche Verknüpfung ist ein stabiler Geschäftsschlüssel - die Arbeits-E-Mail und idealerweise die Personalnummer. Zuordnung über das falsche Feld, und Sie duplizieren entweder Personen oder überschreiben den falschen Datensatz.
• Stichtagslogik. BambooHR speichert Position und Vergütung als datierte Historienzeilen, HiBob ebenso. Verdichtet man eine Beförderung und eine Gehaltserhöhung auf heute, geht die Nachvollziehbarkeit verloren; schreibt man dieselbe Historienzeile zweimal, entsteht doppelte Historie, die jede Auswertung verzerrt.
• Vorgesetzten-Verweise brauchen Reihenfolge. Das Supervisor-Feld in BambooHR verweist auf einen anderen BambooHR-Mitarbeitenden. Kommen eine neue Führungskraft und ihr Bericht im selben Stapel an, muss erst die Führungskraft angelegt oder aufgelöst und dann die Berichtslinie gesetzt werden - oder ein zweiter Durchlauf folgt, sobald jede ID existiert.
• Listenwerte müssen vorab existieren. BambooHR weist eine Abteilung, einen Bereich, einen Standort oder einen Beschäftigungsstatus zurück, der nicht bereits als Listenwert definiert ist. HiBobs benannte Listen und Freitext-Kategorien müssen vor dem ersten Schreiben mit den BambooHR-Listen abgeglichen werden, nicht erst zur Laufzeit entdeckt.
• Abwesenheits-Einheiten und -Arten. Eine in Arbeitstagen gemessene HiBob-Richtlinie ist nicht automatisch eine in Stunden gemessene BambooHR-Abwesenheitsart. Arten müssen zugeordnet, Einheiten umgerechnet und nur ein System als Eigentümer des Kontostands festgelegt werden.
• Rate-Limits und Pagination. HiBob und BambooHR drosseln und paginieren unterschiedlich. Ein Sync über die gesamte Belegschaft muss höflich blättern, bei Drosselung zurückweichen und sauber wiederaufsetzen, statt eine der APIs zu überrennen und mitten im Lauf abgeschnitten zu werden.
• Teilweise Fehler. Weist BambooHR einen Datensatz wegen eines fehlenden Pflichtfelds zurück, müssen die übrigen 499 trotzdem ankommen. Ein naives Skript bricht den Stapel ab; eine Pipeline isoliert den fehlerhaften Datensatz, meldet ihn und macht weiter.

Wie wir sie bauen und betreiben

Wir behandeln das als Pipeline, nicht als Upload von Hand. Änderungen aus HiBob werden zeitgesteuert abgeholt (oder über HiBob-Lifecycle-Webhooks ausgelöst), validiert, dem richtigen BambooHR-Datensatz zugeordnet und als korrekte Feld-Updates und stichtagsbezogene Tabellenzeilen geschrieben - Vorgesetzten-Verweise aufgelöst und Listenwerte geprüft, bevor irgendetwas gesendet wird.

Die Pipeline ist idempotent: Jede Person und jede Historienzeile trägt eine stabile Kennung, sodass ein erneuter Lauf nie einen doppelten Mitarbeitenden oder eine doppelte Vergütungszeile erzeugt. Sie läuft auf cloud-nativer, vollständig EU-gehosteter AWS-Infrastruktur - Personaldaten verlassen die EU nicht, was den AVV für diese Verarbeitung und Ihre DSGVO-Pflichten sauber hält, ein wichtiger Punkt, wenn personenbezogene Daten zwischen zwei HR-Systemen wandern.

Und dann halten wir sie am Laufen. Monitoring, Alerting, Incident Response und - entscheidend - das Beobachten von API-Änderungen bei HiBob und BambooHR liegen vertraglich bei uns. Sie bekommen einen festen Ansprechpartner und ein SLA, kein Skript, das an dem Tag stillschweigend stehen bleibt, an dem einer der Anbieter eine Breaking Change ausliefert.

Wann sich diese Anbindung lohnt

Wenn Sie eine Handvoll Personen in BambooHR führen und diese selten ändern, ist ein manueller Export oder der gelegentliche Bulk-Upload völlig in Ordnung - und wir sagen Ihnen das auch. Die Anbindung lohnt sich, wenn beide Systeme bei realer Belegschaftsgröße produktiv sind, wenn Ein- und Austritte ständig in Bewegung sind, wenn Positions- und Vergütungshistorie über beide Plattformen konsistent bleiben muss, oder wenn eine Migration lange genug parallel läuft, dass die manuelle Doppelerfassung selbst zur Fehlerquelle wird. Dann ist eine betreute Pipeline günstiger und sicherer als der Datendrift, den sie verhindert.