HR Employee Update Requests
Employees raise change requests for their own details, routed through submit, approve and apply with a hash-chained audit trail.
Why this module
HR Employee Update Requests
Employees ask, you decide
An employee records the field, the value on file, the value they want and a reason. The request defaults to their own employee record, so the person raising it cannot quietly point the change at someone else.
A real approval path, not a free edit
Each request moves draft to submitted to approved to applied, with reject available from submitted. Submit is open to self-service staff, approve and reject are manager-gated, and only an HR officer can mark a request applied. Applied and rejected are final and refuse any further move.
Every step is on the record
Status, employee, field label, current value, requested value and reason are captured to an append-only, sha256 hash-chained audit log on every create and change, so the history of a request cannot be edited away without breaking the chain.
Day in the life
A phone number, end to end
An employee opens Update Requests, records that their mobile phone should change from the old number to a new one and adds a short reason. The request is auto-numbered UPD/2026/00042 and sits in draft. They press Submit and it moves to submitted, which a manager sees and approves, or rejects with the reason on the chatter. Once approved, an HR officer presses Apply and the request lands in its final applied state. Every hop, who did it and the before and after values are written to the hash-chained audit log. The record is now a closed, tamper-evident paper trail of the request and its decisions.
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.
Applied and rejected are marked final in the workflow definition. The engine refuses any further transition from a final state, even one a misconfigured definition might declare, so a closed request cannot be silently reopened or re-applied.
The real submitter is captured before the engine elevates to sudo, so a user who fires a gated transition cannot later approve a request that concerns them, even if they hold an approver group.
Each audit row stores the sha256 of the previous row plus its own fields. Any edit that does not recompute the whole downstream chain is caught by verify_chain(), and chain appends are serialized by a transaction-scoped advisory lock under concurrency.
Requests carry a required company_id defaulting to the active company. Writing a request into a company the user is not a member of is rejected, and any audited cross-company override is recorded as its own audit event.
A transition only fires if it is defined from the record's current state and the user is in one of that transition's allowed groups, so the approve and apply buttons are not just hidden in the form, they are enforced server-side.
References are drawn from a company-shared sequence as UPD/YYYY/NNNNN. If the sequence is missing the create still succeeds with a safe UPD/AUTO fallback rather than failing.
What is inside
Built to do the job, end to end.
- The request model. eh.hr.employee.update holds employee, field label, current value, requested value and reason, with an auto-generated reference and mail.thread chatter for the discussion and decision trail.
- Data-driven workflow. The draft, submitted, approved, applied and rejected states and the submit, approve, apply and reject transitions are loaded as workflow-engine data, so the steps and the groups allowed on each can be reconfigured without code.
- Form, list and menu. A status-bar form with Submit, Approve, Apply and Reject buttons that appear only in the right state, a list of requests, and an Update Requests menu under the HR requests section.
- Security and audit wiring. Access rules for HR admin, officer, manager and self-service groups, plus the shared platform mixins that supply the hash-chained audit log and strict multi-company scoping. This module owns no workflow or audit code of its own.
Honest about the edges
What this does not do, so nothing surprises you.
- This module records and routes the request. It does not automatically write the approved value back onto the hr.employee record. Apply advances the request to its final applied state, and an HR officer makes the actual edit to the employee, so the request stays an auditable instruction rather than a silent field mutation.
- Field label, current value and requested value are free text, not a picklist bound to real hr.employee fields, so the request describes the change in plain language rather than validating it against the target field.
- The shipped transitions use direct group gating (manager approves, officer applies). The underlying engine also supports chained multi-step approval, but this module does not configure an approval chain out of the box.
- Depends on the EH HR Platform layer (eh_hr_core, eh_hr_compat and eh_hr_engine_workflow) for the workflow engine, audit log and group definitions. It is not a standalone add-on to stock Odoo HR.
- Built and tested for Odoo 19 Community. There is no wizard, batch action or scheduled job in this module.
Odoo 19 HR employee update request, employee self-service data change Odoo, HR change request approval workflow, employee information update Odoo Community, hr.employee field change request, HR audit trail hash chained, multi-company HR Odoo, manager approval HR request, submit approve apply workflow Odoo, HR self-service portal request, tamper evident HR audit log, ERP Heritage HR platform
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