EH HR Workflow Engine
State machines as data, not Python.
Why this module
EH HR Workflow Engine
Steps are data, not code
States and transitions live in eh.hr.workflow.definition records. The status field derives its options from the definition, ordered as the definition orders its states. An administrator adds a step from the config screen; no developer, no deploy, no downtime.
Transitions that refuse the wrong move
Every advance is checked against the definition: a transition must be declared from the current state, a final state forbids any further move, and group-restricted transitions reject users outside the allowed groups, with an admin bypass for setup.
One engine, every workflow module
The same mixin backs each feature module on the platform instead of every module re-implementing draft to submit to approve to done. One audited transition path, one status widget contract, one place to reason about how records move.
Day in the life
An administrator adds an approval step without a developer.
A leave correction used to go straight from submitted to approved. Compliance now wants a manager check in between. The administrator opens the workflow definition, adds a review state, and inserts two transitions, submit-to-review and review-to-approved, marking the second as requiring approval and tagging the approver group. The next correction raised carries the new step immediately, its status bar shows review between submitted and approved, and the approve button only appears for the approver group. The person who submitted the correction cannot approve their own request, because the engine captures the original submitter before handing the work to the approval engine. No module was redeployed; the change was three rows of configuration.
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.
A state marked final forbids any further transition, even one a misconfigured definition mistakenly declares from it. is_final is the authoritative terminal marker, checked before the transition lookup, so a done record cannot be nudged back into motion.
action_transition resolves the transition strictly from the record's current state. A transition code that is not declared from where the record actually sits raises a clear UserError instead of silently writing an out-of-order state.
Transitions carry an allowed-groups set. A user outside every allowed group is refused, with an explicit admin bypass so a configurator can drive workflows during setup. An empty group set means any owner may execute the step.
When a transition opens an approval chain, the real submitter is captured as submitted_by before the engine is called under sudo, so the user who fired the gated transition cannot later approve their own request even if they hold an approver group.
The state write is unconditional; requires_approval opens a chain as a side effect that gates the follow-up approve or refuse step, not the current one. This avoids records appearing stuck in their pre-submit state and the duplicate approval requests that the older skip-the-write behaviour produced.
action_transition accepts the transition code positionally for server-side callers or via the transition_code context key for view header buttons, which cannot pass positional arguments, so the same method is callable from both code and a form button.
What is inside
Built to do the job, end to end.
- Models this module adds. eh.hr.workflow.definition, eh.hr.workflow.state, eh.hr.workflow.transition, and the abstract eh.hr.workflow.mixin that consuming models inherit by declaring a workflow code.
- What the mixin gives a record. A status Selection whose options come from the workflow definition, a default initial state on new records, action_transition to advance, a computed state_label, and a platform event emitted on every transition for audit.
- Configuration and access. An admin-only Workflows screen under HR configuration to edit states, transitions, allowed groups, approval flags and post-action methods. HR administrators get full write; HR officers get read-only visibility.
- Programmatic entry point. A registered eh.hr.workflow.engine service exposes apply_transition(record, code), the path the approval engine uses to fire the matching transition once a chain approves.
Honest about the edges
What this does not do, so nothing surprises you.
- This is engine infrastructure for the EH HR Platform, not a standalone end-user app. On its own it provides the configuration screens and the mixin; the visible workflows come from the feature modules that consume it.
- It requires eh_hr_core and is designed for the platform's models. It does not retrofit a state machine onto arbitrary standard Odoo models out of the box; a model must inherit the mixin and declare a workflow code.
- Approval routing, escalation ladders and approver assignment live in the separate approval engine. This module only opens a request and reacts to the follow-up transition; it does not implement the approval chain itself.
- Audit immutability and the platform event log are provided by the core platform layer, not by this module. This module emits transition events into that log rather than owning the tamper-evidence mechanism.
- There is no proration, scheduling, cron, or multi-company partitioning logic in this module. Those concerns belong to the feature modules and engines that sit on top of it.
odoo 17 workflow engine, odoo hr state machine, configurable approval workflow odoo, declarative workflow odoo, odoo statusbar workflow, draft submit approve done odoo, group gated transitions odoo, no code workflow configuration, odoo workflow mixin, self approval guard odoo, odoo 17 community hr, 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.
Modules teams pair with this one.
Premium ERP Heritage modules that extend the same stack, each built to the same engineering bar.
Interactive drag and drop Gantt planner for Odoo 17 Community project tasks with a deterministic server side sche...
Employment Hero Connector is the integration core of the ERP Heritage Employment Hero suite, providing per compan...
The United Kingdom country pack for the ERP Heritage Employment Hero integration
Sync Employment Hero employees, departments and payroll bank details into standard Odoo Community HR over the pla...
Inbound webhook receiver for the Employment Hero people and payroll platform on Odoo 17 Community
Real-time fiscalisation of customer invoices and credit notes with the Mauritius Revenue Authority e-Invoicing (E...
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Discuss (mail)
• Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 1131 |
| Technical Name |
eh_hr_engine_workflow |
| License | LGPL-3 |
Please log in to comment on this module