Skip to main content
Die öffentliche Employee-Update-Operation stellt die Eigenschaft blocked bereit. Eine Sperrung ändert den Kontostatus; sie ist keine Löschoperation und darf nicht als Datenlöschung beschrieben werden.

​
Empfohlener Offboarding-Ablauf

​
Mitarbeiter sperren

Verwenden Sie zuerst einen Dry Run, wenn die Änderung Teil eines automatisierten Offboarding-Prozesses ist.

​
Was der öffentliche Vertrag garantiert

  • Die Mitarbeiterressource enthält den booleschen Status blocked.
  • Der Update-Endpoint kann diesen Status ändern.
  • Der Mitarbeiter bleibt über seine Ressourcen-ID adressierbar, solange er im Scope verfügbar ist.
  • Die Public API bietet keine Löschung von Mitarbeitern an.

​
Was der öffentliche Vertrag nicht festlegt

Der OpenAPI-Vertrag beschreibt nicht jeden nachgelagerten Portal- oder Facheffekt eines gesperrten Mitarbeiters. Gehen Sie nicht davon aus, dass eine Sperrung automatisch:
  • Mitarbeiterdaten löscht
  • bestehende Bestellungen storniert, ablehnt oder archiviert
  • Vorfälle oder Anhänge löscht
  • Payroll-Daten löscht
  • ein rechtliches Löschersuchen erfüllt
Behandeln Sie diese Vorgänge über die verantwortlichen JobHandy- und Kundenprozesse.

​
Reaktivierung

Wenn der fachliche Prozess eine Reaktivierung erlaubt, setzen Sie:
Validieren Sie Zielstatus und aktuellen Tenant-Scope vor der Ausführung.

​
Betriebscheckliste

  • JobHandy-Mitarbeiter-ID ist bekannt
  • Aktueller Mitarbeiterstatus wurde gelesen
  • blocked=true wurde per Dry Run validiert
  • Realer Schreibvorgang war erfolgreich und die Request-ID wurde gespeichert
  • Offene Bestellungen und Vorfälle wurden durch den verantwortlichen Prozesseigner geprüft
  • Lokale Zugriffe, Zeitpläne, Secrets und Exporte wurden wie erforderlich behandelt
  • Lösch- oder Betroffenenprozesse wurden separat weitergeleitet
Zuletzt geändert am 27. August 2026