HR Service Request Desk
Employees raise ID card, salary certificate, experience letter and NOC requests; HR takes ownership and closes them on a group-gated, hash-chained workflow.
Why this module
HR Service Request Desk
Stop chasing HR documents over email
Employees pick a request type, add a note, and submit. Every ID card, salary certificate, experience letter and NOC lands in one list with a reference number and a clear status, instead of scattered chat messages and inbox threads.
An HR officer takes each request
From submitted, an HR officer takes the request into In progress and is recorded as assigned. Submit is reserved for the employee; take, complete and reject are reserved for HR officers, so the right person acts at each step.
Every change is recorded and verifiable
State, employee, request type and assignee changes are written to an append-only, hash-chained audit log shared by the platform, plus a full chatter history on each request. The chain can be re-verified to detect any tampering after the fact.
Day in the life
A salary certificate, start to finish
An employee opens Service Requests, picks Salary certificate, writes Need a salary certificate for the bank, and saves. The record auto-numbers as SRV/2026/00042 in Draft. They press Submit and it moves to Submitted. An HR officer presses Take, becomes the owner, and the request goes In progress. The certificate is prepared, the officer presses Complete, and the request reaches Done, a final state that blocks any further edits to the flow. If the request was never valid, the officer presses Reject from Submitted instead and it lands in Rejected. Every step, including who acted and the before and after values, is captured in the chatter and the hash-chained 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.
Done and Rejected are marked final. The engine refuses any further transition out of a final state, even one a misconfigured definition might declare, so closed requests cannot be silently reopened through the workflow.
Submit is allowed only for the employee-self group; take, complete and reject only for the HR officer group. A user outside a transition's allowed groups gets a clear refusal rather than a partial state change.
Each audited change writes a row whose sha256 hash chains to the previous row. Appends are serialized with a Postgres transaction-scoped advisory lock, so concurrent writes cannot fork the chain, and verify_chain re-walks it to find the first broken row.
Company is required and defaults to the active company. A write that moves a request into a company the user does not belong to is rejected even under sudo, unless an explicit audited override context is set, and the elevation is itself logged.
The SRV reference is generated from a dedicated, company-independent sequence only when the record is first saved, is read-only, and is excluded from copy, so duplicating or re-saving never reissues or collides a number.
A transition is only valid from its declared source state, so a double-clicked Submit or Take cannot advance a record twice or skip a step; the second attempt is refused because the source state no longer matches.
What is inside
Built to do the job, end to end.
- One model. eh.hr.service.request, with employee, request type (ID card, salary certificate, experience letter, no-objection certificate or other), free-text description, assigned officer, auto reference and workflow status.
- Five states, four transitions. Draft, Submitted, In progress, Done and Rejected, wired as configurable workflow definition records with Submit, Take, Complete and Reject transitions, each gated to a security group.
- Composed, not reinvented. The module inherits the platform workflow, audited and company-aware mixins plus mail.thread chatter. It ships no workflow or audit engine code of its own, only the request model, its states and its views.
- Views and menu. A list and a form with a statusbar and header action buttons, under an Employee Requests menu, visible to HR officers. Access rights are split across HR admin, HR officer and employee-self groups.
- Tests included. Post-install tests cover default reference generation, the default request type, the full submit to take to complete path, and the submit to reject path.
Honest about the edges
What this does not do, so nothing surprises you.
- This module manages the request and its lifecycle. It does not generate or render the actual document, PDF certificate or ID card; the description and chatter hold the working detail.
- The shipped workflow uses group-gated transitions, not the multi-step approval engine. There is no approval chain, escalation ladder or SLA timer on service requests out of the box.
- The audit log, workflow engine and security groups live in the EH HR Platform base modules (eh_hr_core, eh_hr_compat, eh_hr_engine_workflow), which are required dependencies.
- Request types are a fixed five-option selection (ID card, salary certificate, experience letter, NOC, other); adding new types is a code or studio change, not end-user configuration.
- There is no employee self-service portal view here; requests are handled from the backend Employee Requests menu by users with the relevant HR groups.
- No email or activity reminders are scheduled by this module; notification relies on the standard chatter on each record.
Odoo 17 HR service request, employee document request Odoo, salary certificate request workflow, experience letter request, no-objection certificate Odoo, ID card request HR, HR helpdesk for employees, HR officer assignment Odoo, hash-chained audit trail HR, multi-company HR requests, group-gated workflow Odoo, EH 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.
Modules teams pair with this one.
Premium ERP Heritage modules that extend the same stack, each built to the same engineering bar.
The Australia country pack for the ERP Heritage Employment Hero integration
Sync certifications, qualifications and employee document metadata from the Employment Hero people platform into...
Sync Employment Hero leave categories, leave requests and leave balances into the standard Odoo Time Off app, wit...
Show the Hijri (Umm al-Qura) date alongside Gregorian dates across Odoo 17
Connect Odoo partner records to the Saudi SPL National Address service and the Wathq commercial registry
One click install of the full Employment Hero integration for Odoo Community, covering the connector, two way syn...
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Employees (hr)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 1334 |
| Technical Name |
eh_hr_service_request |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
Please log in to comment on this module