Workable BambooHR Schnittstelle

Was eine Workable-BambooHR-Anbindung wirklich leistet

In Workable passiert die Einstellung: Der Kandidat wird gefunden, interviewt, bekommt ein Angebot und wandert schließlich auf die Stufe Hired - mit Stelle, Abteilung, Standort, einstellender Führungskraft und angenommenem Angebot. In BambooHR wird aus dieser Person ein Mitarbeiter: ein Datensatz mit Eintrittsdatum, Stellendaten, Vergütungshistorie, Berichtslinie und einem Onboarding-Paket.

Zwischen diesen beiden Systemen sitzt heute jemand, der Felder von einem Browser-Tab in den nächsten überträgt - Name, E-Mail, Position, Abteilung, Eintrittsdatum, Gehalt - und dabei oft genug eines falsch macht, sodass Lohnabrechnung oder Organigramm später korrigiert werden müssen. Eine Workable-BambooHR-Anbindung schafft diesen Schritt komplett ab. Sobald ein Kandidat als eingestellt markiert wird, liest die Pipeline die strukturierten Daten, die Workable ohnehin schon hat, mappt sie auf die Felder und Listenwerte von BambooHR und legt den Mitarbeiter an, damit das Onboarding noch am selben Tag beginnen kann.

Welche Daten fließen

Objekt / Ereignis in Workable	Wird in BambooHR zu	Hinweis
Kandidat auf Stufe Hired	Neuer Mitarbeiterdatensatz	Das auslösende Ereignis; die Anlage ist an diese Stufe (oder ein unterschriebenes Angebot) gebunden
Persönliche Daten & Kontaktfelder	Persönlich-Reiter (Name, E-Mail, Telefon, Adresse)	Nur von Workable geführte Felder; BambooHR-eigene Onboarding-Felder bleiben unberührt
Stelle / Requisition	Zeile in den Stellendaten (Position, Abteilung, Bereich, Standort)	Auf die exakten BambooHR-Listenwerte gemappt, nicht als Freitext
Eintrittsdatum	Eintrittsdatum + Gültigkeitsdatum der Stellendaten	Steuert das Gültigkeitsdatum jeder datierten Tabellenzeile
Angenommenes Angebot	Zeile in der Vergütungstabelle	Vergütungshöhe, -art, Abrechnungszeitraum, Währung als datierter Eintrag
Einstellende Führungskraft	Vorgesetzter / Berichtslinie	Auf eine bestehende BambooHR-Mitarbeiter-ID aufgelöst, nicht als Namenstext
Lebenslauf, Angebotsschreiben, Anhänge	Mitarbeiterdokumente	Optional; Dokumente werden dem neuen Mitarbeiter zugeordnet

Das genaue Feld-Mapping, die Übersetzungstabelle der Listenwerte und die Frage, welche Felder maßgeblich sind, werden einmalig im Scoping abgestimmt und in der Pipeline hinterlegt. Danach tippt niemand mehr eine Einstellung von Hand ab.

Die Details, an denen einfache Syncs scheitern

Eine Ein-Klick-Anbindung oder ein nächtlicher Export bringt Sie zu den einfachen 80 % und lässt die teuren 20 % auf dem Schreibtisch Ihrer Recruiter liegen:

• Listenwerte müssen exakt passen. BambooHR validiert Abteilung, Bereich und Standort gegen konfigurierte Listen. Workables “Engineering - Berlin” ist nicht BambooHRs “Engineering” plus Standort “Berlin, DE”. Ohne gepflegte Übersetzungstabelle weist die API den Datensatz entweder ab oder legt still Müll-Listeneinträge an, die Ihre Auswertungen verunreinigen.
• Die Führungskraft ist eine ID, kein Name. Die Berichtslinie in BambooHR zeigt auf eine Mitarbeiter-ID. Ein Führungskraft-Name aus Workable muss auf diese ID aufgelöst werden - und sinnvoll behandelt werden, wenn die Führungskraft noch gar nicht in BambooHR steht.
• Dubletten und Wiedereinstellungen. Kandidaten bewerben sich mit privaten E-Mail-Adressen, manche sind ehemalige Mitarbeiter. Der Abgleich über einen natürlichen Schlüssel vor der Anlage verhindert, dass eine Wiedereinstellung eine zweite Mitarbeiter-ID öffnet und still Personalstand und Betriebszugehörigkeit verfälscht.
• Vergütung ist eine datierte Tabelle, kein Feld. BambooHR führt die Vergütung als datierte Zeilen. Höhe, Art, Zeitraum und Währung aus dem Angebot müssen als korrekt datierter Eintrag landen, sonst zieht die nachgelagerte Lohnabrechnung den falschen Wert.
• Nicht überschreiben, was BambooHR gehört. Menschen werden eingestellt, bevor Steuer-ID, Bankverbindung und Notfallkontakte erfasst sind - die holt der BambooHR-Onboarding-Self-Service ein. Die Pipeline muss die vom Recruiting geführten Felder befüllen und darf die Felder, die Mitarbeiter oder HR später ausfüllen, nie überschreiben.
• Idempotenz und Rate-Limits. Ein erneuter Lauf oder eine erneut zugestellte Webhook-Nachricht darf den Mitarbeiter nie doppelt anlegen, und die Pipeline muss bei einem Schwung Einstellungen am selben Tag die Rate-Limits von Workable und BambooHR einhalten.

Wie wir sie bauen und betreiben

Wir behandeln das als ereignisgesteuerte Pipeline, nicht als geplanten Massenexport. Ein Workable-Webhook (oder ein abgesicherter Poll) löst aus, sobald ein Kandidat die Stufe Hired erreicht; die Pipeline validiert die Nutzlast, löst Führungskraft und Listenwerte auf, gleicht gegen bestehende BambooHR-Mitarbeiter ab und legt den Datensatz mit dem abgestimmten Feld-Mapping an oder aktualisiert ihn.

Die Pipeline ist idempotent: Jede Einstellung trägt eine stabile Kennung, sodass ein erneut zugestelltes Ereignis nie einen doppelten Mitarbeiter erzeugt. Sie läuft auf cloud-nativer, vollständig EU-gehosteter Infrastruktur - personenbezogene Kandidaten- und Mitarbeiterdaten 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 von API-Änderungen bei Workable und BambooHR liegen vertraglich bei uns. Das Onboarding hängt nicht mehr daran, dass jemand daran denkt, eine Einstellung vor dem ersten Arbeitstag zu übertragen.

Wann sich diese Anbindung lohnt

Wenn Sie eine Handvoll Menschen pro Quartal einstellen, ist die native Übergabe oder sogar die manuelle Erfassung völlig in Ordnung - und wir sagen Ihnen das auch. Die Pipeline lohnt sich, wenn das Einstellungsvolumen konstant ist, wenn Vergütung und Berichtslinien auf Anhieb stimmen müssen, wenn Dubletten und Wiedereinstellungen bereits Ihre Personalstandsauswertung verfälschen, oder wenn der Übergang vom Recruiting ins Onboarding zur wiederkehrenden Quelle von Fehlern am ersten Arbeitstag geworden ist, die eine Pipeline hätte verhindern sollen.