EH HR Background
Pre-hire and employee background checks, tracked from request to clearance on a hash-chained audit trail.
Why this module
EH HR Background
One audited platform, not a side tool
Background checks live in the same database as the rest of your HR, on the shared workflow and audit engines, instead of a spreadsheet or a separate system to buy, build and keep in sync.
A clearance you can prove
Each request, state change and edit is written to the append-only, hash-chained audit log. You can show who cleared or flagged a candidate, and when, and verify the chain has not been altered after the fact.
Only the right people advance a check
Request, start, clear and flag are guarded transitions limited to HR Officers, and the cleared and flagged states are final, so a closed verification cannot be quietly reopened or re-fired.
Day in the life
From request to a defensible clearance
An HR Officer opens a new background check for a candidate, picks the check type (say, criminal), and notes the screening agency. Saving mints an auto-numbered reference like BG/2026/00001 and shows the status bar at Draft. The officer hits Request, then Start once the agency is engaged; each move advances the workflow and writes a row to the audit log with the from and to state, the actor and the owning company. The result comes back clean, the officer records it in the result field and clicks Clear, landing the check in a final Cleared state. Had the agency raised something, Flag would have moved it to a final Flagged state instead. Months later an auditor with read-only access verifies the audit chain over the whole log and confirms nothing was edited after the clearance was recorded.
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.
Cleared and flagged 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 check cannot be reopened or have its outcome re-fired.
When a transition is configured to require approval, the engine captures the real submitter before it elevates to sudo, so the user who fired a gated transition cannot later approve their own request even if they hold an approver group.
The audit log is inherently serial because each row's hash folds in the previous row's hash. Appends take a transaction-scoped Postgres advisory lock, so two checks cleared at the same instant chain cleanly with no fork.
The audited mixin captures a before snapshot of only the whitelisted fields (state, employee, check type, agency, completed date). A save that changes none of them emits no audit row, so the trail stays signal, not noise.
company_id is required and defaults to the active company. A cross-company move is refused even under sudo unless an explicit override context key is set, and any such elevation is itself written to the audit log with every affected record id.
References are drawn from a shared ir.sequence on save and default to BG/AUTO if the sequence is missing, so a saved check always carries a stable, non-copyable reference.
What is inside
Built to do the job, end to end.
- One model, eh.hr.background. A background check carries an employee or candidate (delete-restricted), a check type from five fixed options (criminal, education, employment, reference, credit), an optional agency, a free-text result, a completed date, and an auto-numbered reference. It composes the platform workflow, audited and company-aware mixins plus mail.thread for chatter.
- Request to clearance workflow. A five-state machine (draft, requested, in progress, cleared, flagged) with four transitions: request, start, clear and flag. Cleared and flagged are final. The status bar and transition buttons are driven by the shared workflow engine, with each step gated to the HR Officer group.
- Owns no engine code. The module ships one Python model, a workflow definition, a sequence, list and form views and a menu. The audit log, the hash chain, the state machine and the company isolation all live in eh_hr_core and eh_hr_engine_workflow. This module configures them, it does not re-implement them.
- Four-tier access. HR Admin has full control, HR Officer can read, create and edit (but not delete), and HR Manager has read-only visibility. The Background Checks menu sits under HR records and is shown only to officers and above.
Honest about the edges
What this does not do, so nothing surprises you.
- Background checks are run and recorded manually. The module does not integrate with any external screening agency, portal or API; the agency and the result are recorded by hand.
- The five check types (criminal, education, employment, reference, credit) are a fixed selection in code, not user-configurable record types.
- There is no automated reminder, SLA timer or escalation. A check sits in its current state until a user advances it.
- The outcome is a single free-text result field. There is no structured per-item scoring, attachment vault or document storage beyond standard chatter.
- Approval routing exists in the underlying engine but the shipped background workflow uses direct officer-gated transitions, not an approval chain.
- This branch targets Odoo 19 Community. The listing page also references 16 to 19 as the platform lineage; confirm the build for your series before deploying.
Odoo HR background check, Odoo pre-hire screening, Odoo employee verification, Odoo criminal record check, Odoo reference check, Odoo education verification, Odoo employment verification, Odoo credit check HR, candidate screening Odoo, onboarding compliance Odoo, Odoo HR vetting workflow, tamper evident HR audit Odoo, Odoo 19 Community HR, audited HR records 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.
Please log in to comment on this module