HR Service Request Desk
Employees raise HR document requests, officers take ownership, every step lands on a hash-chained audit trail.
Why this module
HR Service Request Desk
One desk for HR paperwork
Employees pick a request type (ID card, salary certificate, experience letter, no-objection certificate or other), add a description, and submit. A yearly SRV reference is generated automatically on save.
Officers take and clear
An HR officer takes a submitted request into progress, assigns a responsible team member, then completes or rejects it. Transition buttons are gated by role, so the right person drives each step.
Every change is recorded
State, employee, request type and assignee changes are written to an append-only, sha256 hash-chained audit log. A built-in verify pass flags any row that was tampered with after the fact.
Day in the life
From request to certificate, with a paper trail
An employee opens a request for a salary certificate, describes what the bank needs, and submits it. The reference SRV/2026/00042 is stamped automatically. An HR officer takes the request, which moves it to in progress, sets themselves as the responsible person, prepares the document, and marks it complete. If something is wrong, they reject it from the submitted state instead. Throughout, the chatter shows the conversation and the audit log holds an immutable, hash-chained record of who advanced the request and when, ready to prove later that nothing was quietly changed.
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.
Once a request reaches done or rejected, both marked terminal, the engine refuses any further transition with a clear error, even if a misconfigured definition declares one from that state.
Submit is reserved to the employee self group, while take, complete and reject require the HR officer group. A user outside the transition's allowed groups is blocked with a permission error rather than silently advancing the request.
The audit log is a serial hash chain. A transaction-scoped Postgres advisory lock serializes appends, so two requests transitioning at the same moment cannot fork the chain or read the same tail.
Each audit row hashes the previous row plus its own fields, so editing any historic row breaks the downstream chain. verify_chain walks the log with keyset pagination and returns the first broken row id, scaling to large logs without loading them all.
company_id is required and defaults to the active company. An attempt to move a request to a company the user does not belong to is refused, and any permitted cross-company write is itself written to the audit trail.
The SRV reference is only assigned when the name is still New, and falls back to SRV/AUTO if the sequence is missing, so saving never produces a blank or duplicated reference.
What is inside
Built to do the job, end to end.
- Request model and types. eh.hr.service.request with employee, request type (ID card, salary certificate, experience letter, NOC, other), free-text description and an assigned-to officer. Yearly padded SRV sequence, list and form views, and a chatter for discussion.
- Configurable workflow. A five-state definition (draft, submitted, in progress, done, rejected) with submit, take, complete and reject transitions loaded as data. States and ordering come from the platform definition, so the path can be adjusted without code changes.
- Audited, company-aware mixins. Inherits the platform workflow, audited and strict company-scope mixins. State, employee, request type and assignee changes are captured into the append-only hash-chained audit log, scoped per company for clean read isolation.
- Security and menus. Access rules for HR admin, HR officer and employee self groups, with create and update for staff and delete reserved to admin. A Service Requests menu sits under the platform's requests section for officers.
Honest about the edges
What this does not do, so nothing surprises you.
- This module manages the request and its workflow only. It does not generate or render the actual document (no PDF or certificate template is produced), so the officer prepares the deliverable outside the request.
- There is no approval chain configured here. Requests move directly through officer-driven transitions rather than a multi-level approval ladder, although the underlying engine supports gated approvals for other document types.
- It requires the EH HR Platform engine modules (eh_hr_core, eh_hr_compat, eh_hr_engine_workflow) and the standard hr app. It is not a standalone helpdesk and does not replace a general ticketing system.
- No scheduled jobs, SLA timers or automatic escalation are included. Progress depends on an officer taking and clearing the request.
- The workflow and audit behaviour are provided by the shared platform engine, not by this module, so those capabilities are common to the suite rather than unique to service requests.
HR service request Odoo, employee self service HR, salary certificate request, experience letter request, no-objection certificate, ID card request HR, HR document workflow, HR ticketing Odoo 19, tamper-evident audit trail, multi-company HR, HR officer workflow, hash-chained audit log
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