HR Disciplinary Actions
Run progressive discipline through a configurable workflow with employee acknowledgement and a tamper-evident audit trail.
Why this module
HR Disciplinary Actions
Every change is on the record
State changes and key field edits are written to an append-only audit log where each row carries the sha256 of the previous row. A single edit anywhere breaks the chain, so the history is tamper-evident, not just logged.
The ladder does the counting
Each warning has a validity window. The system counts an employee's other warnings still active on the issue date and recommends the next step up the ladder, from verbal to written to final, so escalation follows a consistent rule instead of memory.
Acknowledgement is a real step
Issued warnings move to acknowledged through a self-service transition before a manager can close them, and the employee response is captured on the record. The workflow makes the acknowledgement a gate, not an optional note.
Day in the life
From incident to closed case
A manager opens a new disciplinary record for an employee, writes the reason, and clicks Apply Recommended to set the action type the escalation ladder suggests from the employee's active warnings. Issue moves it to issued and stamps the audit log. The employee acknowledges, recording their response. The manager closes the case once resolved. Months later the warning lapses past its validity window and stops counting toward the next escalation, while the full state history stays intact and verifiable in the hash-chained audit trail.
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.
The audit log is append-only and hash-chained. Each row stores the sha256 of the prior row plus its own fields, and verify_chain walks the chain to flag the first row that does not match, so silent edits are detectable.
Audit appends take a transaction-scoped Postgres advisory lock so concurrent writes serialise rather than fork the chain. The hash material is identical on append and verify, so actorless rows do not break verification.
The escalation count excludes the warning being evaluated and any cancelled warning, and only counts warnings whose validity window still covers the issue date, so the recommended next step reflects genuinely active prior warnings.
A warning past its validity window is no longer active and drops out of the escalation count automatically, so old issues stop inflating the recommended action without anyone having to clean them up.
Closed and cancelled are terminal. The workflow engine refuses any further transition out of a final state, even one a misconfigured definition might declare, so a closed case cannot be quietly reopened through the state machine.
Records require a company and reject cross-company writes, even under sudo, unless an explicit audited override context is set. Cross-company elevation is itself written to the audit log with every affected record id.
References auto-number as DISC and the year, padded to five digits, on create. The sequence is company-independent so the reference series is continuous across companies.
What is inside
Built to do the job, end to end.
- Workflow engine, not hard-coded states. The draft, issued, acknowledged, closed and cancelled states and the transitions between them come from a workflow definition record, resolved dynamically. The status bar and transition buttons are driven by that definition, so the lifecycle is configurable without code.
- Group-gated transitions. Issue, close and cancel are restricted to the HR manager group, while acknowledge is available to the employee self group. A transition fired by a user outside its allowed groups is refused, so the lifecycle enforces who may do what.
- Validity, expiry and active state. Each warning takes a validity in months, defaulting to twelve. The expiry date is computed and stored from the issue date, and an is-active flag reflects whether the warning is still within its window and not cancelled.
- Escalation ladder. The recommended action is computed from the count of the employee's other active warnings, mapping zero, one and two or more priors to verbal, written and final. One button applies the recommendation to the action type.
- Audit and chatter. State, employee, action type, severity and reason changes are captured in the platform audit log, and the form carries a chatter with field tracking for an at-a-glance change history alongside the immutable trail.
- Built on the EH HR Platform. The module owns no workflow or audit code of its own. It depends on the EH HR core, compat, and workflow engine modules and consumes their mixins, so behaviour is consistent with the rest of the platform.
Honest about the edges
What this does not do, so nothing surprises you.
- This module covers verbal, written, suspension and final warning types only. It is not a grievance, investigation case-management or termination module.
- The disciplinary workflow advances on manager and employee actions and is not routed through a multi-step approval chain in this module, even though the underlying engine supports gated approvals elsewhere.
- Escalation produces a recommended next action and applies it on request. It does not auto-issue warnings or take action on the employee without a user.
- There is no built-in document attachment template, letter generation, or e-signature step beyond the free-text acknowledgement field and the standard chatter.
- The audit log and its verification live in the EH HR core module, which is a required dependency. This module emits to that log rather than providing its own.
- Targets Odoo 18 Community. It is not packaged for or tested against other Odoo versions in this listing.
odoo 18 hr disciplinary, employee disciplinary action odoo, progressive discipline odoo, warning management hr, verbal written warning workflow, suspension final warning odoo, hr audit trail odoo, tamper evident audit log, disciplinary escalation ladder, employee acknowledgement workflow, odoo community hr discipline, multi company hr odoo, hr workflow engine odoo, warning expiry validity hr, disciplinary case tracking
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