Skip to main content

Resignation and Exit Storage

Audience​

Developers, QA and support engineers, data reviewers, implementation partners, solution architects, privacy reviewers and security reviewers.

Reference Content​

Summary​

Resignation and exit persistence is implemented in the compatibility application through ExitRequest and workforce/user records. It is not stored by the extracted Employee context.

Exit model​

The exact allowed transitions are application-controlled; the diagram summarizes observed operations rather than a database constraint.

Stored responsibilities​

ExitRequest holds the employee/workforce reference, requested and last-working-day information, reason, decision state, decision metadata and access-revocation state. Tenant filtering applies in the compatibility context.

Save behavior​

  • Creation writes the request and local audit evidence in the compatibility context.
  • Approval or rejection changes the request and records evidence locally.
  • Access revocation updates the user, workforce record, exit request and audit record before one compatibility-context save.
  • Approval notification occurs after the approval save and is not part of the same database transaction.

Missing enforcement​

No verified database relationship to Asset Service, final-settlement record, leave closure, attendance closure or extracted Employee status exists.

Requires confirmation​

Unless explicitly confirmed above, production migration governance, rollback, reconciliation, retention, privacy, performance, concurrency and operational ownership require confirmation.

Source References​

  • Models/ExitRequest.cs
  • Models/ExitRequestAuditLog.cs
  • Controllers/HrOperationsController.cs
  • Data/AppDbContext.cs

See Also​

Keywords​

  • Onboarding database
  • Offboarding database
  • Lifecycle persistence

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-20
  • Review cycle: Quarterly