HR Policy Acknowledgement
Publish company policies, capture who read them, and keep the proof on a hash-chained audit trail.
Why this module
HR Policy Acknowledgement
Policies under a real workflow
Every policy runs the platform state machine: draft, published, archived. Publish and archive are gated to the HR Officer group, and the archived state is final, so a retired policy cannot be silently reopened.
Acknowledgement you can show
Each policy carries a list of per-employee acknowledgements. One click stamps the acknowledged flag and the date, giving you a dated record of who confirmed they read a given policy version.
Changes you cannot quietly rewrite
State, title, category, and version changes are written to an append-only, hash-chained audit log serialised by a Postgres advisory lock, so tampering with a past row breaks the chain and is detectable.
Day in the life
An HR officer rolls out a refreshed code of conduct.
She opens a new policy, sets the title, category HR, and version 2024-Q2, and pastes the text. The record auto-numbers POL/2024/00042 and sits in draft. She clicks Publish; because she is in the HR Officer group the transition is allowed, the status bar moves to Published, and the change lands on the audit trail. On the Acknowledgements tab she adds the team, and each person clicks Acknowledge to stamp their name and date. When the policy is later superseded she archives it, a final state, so the record stays as historical proof without being editable back into circulation.
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.
Archived is marked final in the workflow definition. The engine refuses any further transition out of a final state, even one a misconfigured definition might declare, so retired policies stay retired.
Publish and archive are restricted to the HR Officer group. A user outside the allowed groups (and not an admin) is blocked with a clear error rather than silently advancing the policy.
Audit rows are hash-chained: each row hashes the previous row plus its own fields. A transaction-scoped advisory lock serialises appends so concurrent writes cannot fork the chain, and any later edit fails chain verification.
Policies carry a required company and refuse cross-company writes, even under sudo, unless an explicit audited override context is set. Every such elevation emits its own audit row recording the affected record ids.
Each policy draws a year-prefixed reference from a shared sequence on create, and the reference is read-only and not copied, so duplicating a policy never clones its number.
Acknowledgements cascade-delete with their policy but reference employees with ondelete restrict, so an employee tied to acknowledgement history cannot be deleted out from under the record.
What is inside
Built to do the job, end to end.
- Company policy record. A policy model with title, category (HR, IT, safety, finance, general), a free-text version label, auto-generated reference, and the full policy body, with a chatter for discussion and tracking on key fields.
- Acknowledgement register. A child acknowledgement model linking employee to policy, with an acknowledged flag, an acknowledged-on date, and an Acknowledge button that stamps both in one click from the policy form.
- Workflow and audit composition. The policy composes the platform workflow, audited, and company-aware mixins, so the state machine, hash-chained audit emission, and strict multi-company scoping come from the shared engine rather than bespoke code.
- Menus and access control. A Company Policies menu under HR records, plus access rules giving HR admins full control, HR officers create and edit, and self-service employees read-only visibility of policies.
Honest about the edges
What this does not do, so nothing surprises you.
- The version field is a free-text label (such as 1.0 or 2024-Q2). The module does not chain or supersede versions automatically; publishing a new version is a new or updated record, not an automatic revision history.
- Acknowledgement is recorded from the back-office policy form. There is no employee self-service portal page or email campaign that pushes a policy to staff and forces sign-off before access.
- Acknowledgement is captured per employee but is not enforced. The module does not block, remind, or escalate against employees who have not yet acknowledged a published policy.
- Policies are not gated by an approval chain. Publish and archive are role-restricted but immediate; this module does not route policy publication through a multi-step approver ladder.
- There are no scheduled jobs. Nothing runs on a cron to expire, re-circulate, or chase outstanding acknowledgements automatically.
- Requires the EH HR Platform base (core, compat, and workflow engine). It is a consumer module and is not a standalone policy app.
Odoo 19 HR policy management, policy acknowledgement tracking, employee handbook sign-off, company policy compliance Odoo, HR policy workflow, audit trail HR Odoo, multi-company HR policy, policy attestation Odoo Community, versioned policy distribution, who acknowledged policy Odoo
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