Onboarding & Offboarding Business Overview
Summary
This page defines the verified purpose, actors, responsibilities, lifecycle scope, maturity, and exclusions of the cross-domain capability.
Audience
Employees, managers, recruiters, HR administrators, product owners, QA, support, security, and solution architecture reviewers.
Overview
Onboarding and offboarding are implemented across Recruitment, Employee, HR Operations, and downstream services rather than as one bounded context.
Business purpose
Onboarding converts an accepted Recruitment offer into an Employee record and a Joined candidate state. Offboarding lets an employee submit a resignation request, lets authorized managers or administrators decide it, permits a pre-last-working-day rollback, and lets an authorized administrator complete access revocation after the last working day.
Business architecture
Primary actors and verified responsibilities
| Actor | Verified responsibility | Boundary |
|---|---|---|
| Candidate | Accept or decline a tokenized offer | No onboarding self-service form |
| Recruiter / HR user | Move accepted offers, update onboarding status, enter completion data | Coarse Recruitment access; final ownership Requires confirmation |
| Employee | Submit and view own resignation; request rollback where permission is present | Self-service is limited to exit |
| Manager | View and decide direct-report exit and rollback requests where team permissions exist | Cannot approve own exit |
| HR administrator / administrator | Tenant-wide exit decisions and post-date access revocation | Extracted onboarding authorization remains Foundation |
| Payroll, attendance, leave, asset administrators | Operate their separate modules | No unified onboarding/offboarding task orchestration |
Supported lifecycle
The verified cross-domain sequence includes Candidate stages through Selected and Joined, onboarding statuses Pending, In Progress, Completed, and Cancelled, Employee statuses Active, On Leave, Suspended, and Terminated, plus separate exit-request states. “New Hire,” “Notice,” “Exit,” and “Archived” are not canonical Employee statuses. Notice is represented by an exit request and notice-status text; archival is Not implemented.
Current maturity
- Transitional: gateway-selected monolith and extracted Recruitment completion paths differ.
- Partial: the UI gathers more completion data than the extracted path consumes.
- Foundation: generic onboarding tasks and asset-clearance query exist without end-to-end orchestration.
- Not implemented: one business process coordinating onboarding and offboarding across all modules.
Confirmed exclusions and Requires confirmation
No source-backed policy establishes mandatory document types, checklist templates, IT accounts, asset bundles, induction/training, probation setup, automatic balance creation, final settlement, clearance sign-off, exit interview, knowledge transfer, retention schedule, or legal compliance. Manager responsibility during onboarding is limited to an optional reporting-manager selection; manager onboarding tasks Require confirmation.
Source References
microservices/src/recruitment-service/Domain/Recruitment/Onboarding.csmicroservices/src/recruitment-service/Domain/Common/Enums.csmicroservices/src/employee-service/Domain/Employees/Employee.csControllers/HrOperationsController.csUI/salary-ui/apps/client-hrms-portal/src/pages/hr/HrOperationsPage.tsx
Related Articles
See Also
Keywords
- Onboarding business overview
- Offboarding business overview
- Workforce lifecycle
Revision Information
- Status: Draft
- Last reviewed: 2026-07-20
- Review cycle: Quarterly