Employment Hero HR Sync for Odoo
Bring employees, teams and bank details from the people platform into standard Odoo HR, with field mappings and sync jobs you tune in the interface, no code.
Store price is USD 157 all-in: installing this also pulls the 2 paid ERP Heritage modules it depends on.
Why this module
Employment Hero HR Sync for Odoo
Tune the mapping, not the code
Endpoints, field mappings and sync jobs ship as data, not hard coded logic. The starter mappings cover name, work email, job title, phone, birthday and the department relation, and you adjust source paths to your own organisation's payload from the interface. The records install with no update protection so an upgrade never overwrites your tuning.
Re run a job without fear
Every record is keyed by its Employment Hero id through a cross reference table, so a re run updates in place instead of duplicating. An unchanged payload is a no op, one bad record is isolated in a savepoint and logged while the rest of the batch continues, and the run ends in a partial state rather than aborting everything.
Bank numbers encrypted at rest
Synced employee bank account numbers are stored as ciphertext in the database and decrypt only for HR users on read. A shipped migration encrypts any legacy plaintext column on upgrade and drops it, so an existing install is cleaned up rather than left leaking in a database dump.
Day in the life
From people platform to Odoo HR, on a schedule
You connect once, then enable the Departments and Employees jobs. A scheduled run pulls teams into hr.department first so the relation resolves, then pulls employees into hr.employee, matching each to its department through the external id cross reference. New joiners create, leavers and edits update in place, and the run history shows exactly what was created, updated, skipped or failed. Bank details ride along into a dedicated model that keeps the account number off the partner banking used by Accounting, encrypted at rest. When you are ready, you narrow the push domain and turn on the outbound leg so selected Odoo edits flow back to the platform. Nothing surprises you, because a dry run previews every change first.
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.
Records are keyed by external id through the cross reference, so re running a job updates in place and never creates a second copy. A payload that has not changed since the last run is skipped as a no op.
The skip check hashes the mapped values together with a fingerprint of the mapping itself, so editing a mapping line (a new field, a different transformer) forces existing records to be rewritten on the next run instead of being wrongly skipped as unchanged.
Each record is processed inside its own savepoint. A failed write, for example an integrity error, rolls back just that record and is logged as an error line; the rest of the batch still applies and the run ends partial.
Departments run before employees by sequence so the employee to department link resolves through the cross reference. The department source path ships as a best guess (primary team) for you to align to your organisation's payload.
Transient failures (5xx, timeouts) and 429 rate limits are retried with exponential backoff and jitter. A server Retry-After header is honoured and clamped to a ceiling so a bad header cannot park a worker for hours; non retryable errors raise at once.
Outbound create and update calls carry a stable Idempotency-Key, reused across every retry, so a resent write is deduplicated by the platform rather than creating a duplicate record.
A token bucket meters requests against the platform's budget. The default database backed bucket shares one budget across workers, so a multi worker deployment does not multiply into a 429 storm.
List reads page through results using the platform's page index and size parameters and stop on a short or empty page. If a hard page cap is reached the run logs a loud truncation warning instead of silently dropping records.
An account number is encrypted before it is stored and renders a placeholder when the key is unavailable. It is pull only and never pushed back, and a legacy plaintext column is migrated and dropped on upgrade.
Connections, jobs and synced records carry a company. A job resolves the default connection for its product and company, so separate companies sync against their own organisation without crossing data.
What is inside
Built to do the job, end to end.
- Department and employee sync jobs. Two ready jobs: teams into hr.department and employees into hr.employee, ordered so the department relation resolves. Both ship as two way (pull then push) with the inbound default set to Employment Hero wins, and the outbound push left disabled by an empty domain that you narrow before enabling it.
- Starter field mappings. Editable mapping lines for employee name (composed from first and last name), work and private email, job title, work, private and mobile phone, date of birth and the department relation. Department maps its name. You tune source paths to your organisation's payload from the interface.
- Employee bank account model and view. A dedicated eh.hr.bank.account model with list and form views, holding account name, bank name, branch code (BSB or sort code), account number, allocation percentage and primary flag. The account number is encrypted at rest and restricted to HR users, kept off the partner banking used by Accounting.
- Extended HR endpoint catalogue. Endpoints for department create and update, employee quick add, personal, employment and contractor detail updates, plus read coverage for bank accounts, emergency contacts, custom fields, employment histories, cost centres, employing entities, positions and kiosk members. Endpoints alone extend coverage even where no job ships yet.
- Bank account pull job. A bank account sync job and mapping are shipped and ready against the dedicated model. Because bank accounts are an employee sub resource, a deployment drives this per employee by supplying the employee id as a path parameter.
- Upgrade migration. A post migration that encrypts any pre encryption plaintext bank account column into the ciphertext column and drops the old column, with a pre check that fails the upgrade cleanly if the crypto library is missing rather than touching rows.
Honest about the edges
What this does not do, so nothing surprises you.
- This module is configuration on top of the eh_hero_sync engine and the eh_hero_base connector, both of which install as dependencies. It does not contain its own transport or auth code.
- Synchronisation runs manually, on the shared daily schedule, or when you trigger a job. This module does not register a live inbound webhook listener for HR events; the engine has a webhook code path, but no webhook controller or subscription ships here.
- The shipped jobs are configured as two way, but the outbound push is intentionally inert until you narrow its record domain and confirm the mapping, so it does not mass create records in the platform on first run.
- The starter mappings reflect a common payload shape (for example the department relation maps from a primary team id as a best guess). Source paths are meant to be tuned to your own organisation's API response.
- Out of the box this module syncs departments, employees and the dedicated bank account model. The extra endpoints it ships (emergency contacts, custom fields, histories, positions and so on) extend the catalogue but do not all have a mapping or job yet.
- Employee bank account numbers are encrypted at rest and pulled only; they are never pushed back to the platform.
- Requires the standard Odoo Community HR app. No Enterprise dependency, and no chart of accounts or payroll posting is performed by this module.
Employment Hero Odoo integration, Employment Hero HR sync, Odoo HR employee import, department team sync Odoo, employee bank account import, Odoo 19 Community HR connector, idempotent sync engine, external id cross reference, field mapping connector, two way sync Odoo, scheduled HR sync job, OAuth2 people platform connector, PII encrypted at rest, hr.employee hr.department sync, people platform integration
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.
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 19
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...
The Malaysia country pack for the ERP Heritage Employment Hero integration
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Employees (hr)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 4023 |
| Technical Name |
eh_hero_hr |
| License | OPL-1 |
| Website | https://www.erpheritage.com.au/ |
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module