Resignation and Offboarding
Run resignations through a governed lifecycle with notice dates, an exit clearance gate, and a tamper-evident audit trail.
Why this module
Resignation and Offboarding
Every departure follows one path
Resignations move through Draft, Submitted, Accepted, Offboarded and Withdrawn. Transitions are gated by HR group, and final states refuse any further change, so the lifecycle cannot be short-circuited.
No offboarding with open clearance
Marking someone offboarded is blocked while any exit clearance item is open. The standard checklist covers IT, manager handover, finance, HR and facilities, so assets and access are accounted for before the record closes.
A trail you can prove
Create, write and state changes are written to an append-only, sha256 hash chained audit log with before and after snapshots, scoped to the owning company. Edits to history are detectable.
Day in the life
From notice to a clean exit
An employee raises a resignation and picks a reason. The last working day fills in from the resignation date plus the notice period, and HR can override it. HR generates the exit clearance checklist, assigns owners for IT, finance and the rest, and submits the request. A manager accepts it. As each clearance item is ticked, the progress bar climbs. Only when every item is done does the Mark Offboarded button complete the record. If circumstances change while it is still submitted, the request can be withdrawn. Every step lands on the audit log.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
action_res_complete raises a UserError listing the record reference when any checklist item is still open, so an incomplete offboarding cannot be forced through the button or a server call.
A resignation with no clearance items is treated as complete, so lightweight cases are not blocked while gated cases still are.
Offboarded and Withdrawn are marked final in the workflow definition; the engine refuses any further transition from a final state even if a misconfigured definition declares one.
Submit and withdraw are limited to employee self service, accept and complete to HR managers. A user outside a transition's groups is refused, not silently ignored.
The company aware mixin defaults company on create and refuses moving a record into a company the user cannot access, and audit rows carry the owning company for per-company isolation.
Each audit row stores the prior row hash and its own sha256, so a deleted or altered entry breaks the chain and is detectable on verification.
Changing the notice period recomputes the last working day from the resignation date, and the field stays overridable for negotiated exits.
What is inside
Built to do the job, end to end.
- Resignation record. eh.hr.resignation with reference number, employee, resignation date, notice period, computed and overridable last working day, reason type and free text reason, plus a clearance progress bar.
- Exit clearance checklist. eh.hr.resignation.checklist lines with area, task, responsible person, done flag and notes. A one click action seeds the standard IT, manager, finance, HR and facilities items.
- Workflow definition and sequence. Data defines the five state lifecycle, the four group gated transitions and the RES/year/00001 reference sequence. The states are configured in data, not hard coded in Python.
- Platform mixins. Inherits the workflow, audited and company aware mixins from the EH HR Platform plus mail thread, so the workflow engine and hash chained audit log are shared, not reimplemented here.
- Access rules and views. Per group access on the resignation and checklist models, a statusbar form with stage buttons, a list with the progress bar, and a menu entry under Human Resources.
Honest about the edges
What this does not do, so nothing surprises you.
- Requires the EH HR Platform base modules eh_hr_core, eh_hr_compat and eh_hr_engine_workflow plus Odoo hr; it owns no workflow or audit code of its own.
- The shipped resignation transitions are group gated but do not open a multi-step approval chain; approval ladder behaviour lives in the platform engine and is not wired into this module's workflow.
- There is no proration, payroll calculation or final pay computation here; finance settlement is tracked as a clearance item, not calculated.
- No scheduled jobs, reminders or automated escalations ship with this module; progression is driven by users.
- The exit clearance areas are a fixed selection (IT, manager, finance, HR, facilities, other) rather than a fully configurable catalogue.
- Targets Odoo 16 Community; it does not depend on Enterprise HR modules.
Odoo 16 resignation, employee offboarding Odoo, exit clearance checklist, notice period, last working day, HR separation workflow, resignation management, exit interview, asset return, access revocation, withdraw resignation, HR audit trail, multi-company HR, employee exit process, offboarding software
Need this fitted to the way you work?
ERP Heritage delivers end to end Odoo work: Odoo Implementation, Customization and Development, Integration, Migration, Consultation, Support and Training. We help teams put this module into production, shape it to their process, and keep it running.
We work with businesses across Australia (Melbourne, Sydney, Brisbane, Perth, Adelaide, Canberra) and the Middle East (Dubai, Abu Dhabi, Riyadh, Jeddah, Doha, Kuwait City, Muscat). Start a conversation at erpheritage.com.au or email info@erpheritage.com.au.
Languages
Available in 19 languages
The interface ships translated out of the box. Switch language in Odoo and the fields, menus, and messages follow.
Please log in to comment on this module