Employment Hero Sync Engine
The synchronisation core every Employment Hero domain module runs on: data driven field mapping, idempotent upsert keyed by external id, separate inbound and outbound conflict policies, per record isolation and a full audit trail.
Store price is USD 98 all-in: installing this also pulls the 1 paid ERP Heritage module it depends on.
Why this module
Employment Hero Sync Engine
Re run as often as you like, no duplicates
Every record carries its external id, source timestamp and a payload hash in a dedicated cross reference. A second run finds the existing row and updates in place, and an unchanged payload is skipped outright. Retries and overlapping schedules stay safe.
One bad record cannot sink the batch
Each record is processed inside its own database savepoint. A failed write rolls back just that record, is logged as an error line, and the run continues and ends in a partial state rather than aborting everything after it. Progress is committed in batches as it goes.
Field mapping is data, not stored code
Dotted source paths map to Odoo fields through a registry of safe, reviewed transformers. Nothing arbitrary is evaluated. Inbound precedence and outbound push gating are separate policies, so turning on a push never silently stops it overwriting the platform copy.
Day in the life
A scheduled run, a webhook, and a fix
Overnight the scheduled cron runs the active jobs. A delta job reads only the records the platform changed since the last successful run, maps each one, and upserts it by external id, skipping anything whose payload hash is unchanged. One employee record has a malformed value, so its savepoint rolls back, it is logged as an error line, and the run finishes partial while everything else lands. Mid morning a single employee changes upstream, the platform fires a webhook, and the matching subscription triggers a targeted pull of just that one record by id, so the delivery and its retries each cost one request rather than re reading the whole endpoint. Before a risky mapping change goes live, an admin runs the job in dry run, reads the preview of what would be created and updated without a single write, then commits the change and lets the next run apply it.
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 repeated webhook for the same record fetches that one entity by id and upserts it. The payload hash makes the second apply a no op, so a redelivery never duplicates or churns the record.
A webhook triggered update is forced to newest wins. A delivery that arrives late with an older timestamp does not overwrite a newer record, and a delivery with no usable timestamp is skipped rather than allowed to win.
The incremental cursor only advances to the latest record that processed successfully, and never past the timestamp of a failed one. A failed or untimed record is re fetched next run instead of being silently skipped forever.
Each record runs in its own savepoint, so an IntegrityError or a bad value rolls back only that record. The rest of the batch commits and the run ends in a partial state with the failure recorded as a line.
An outbound push hashes the payload and carries a stable idempotency key. An unchanged record is not re sent, a retried create repeats its key so the platform deduplicates it, and a record already linked updates rather than creating a second copy.
A delete event archives the linked Odoo record when the model supports it, otherwise unlinks it and severs the cross reference. A hard delete blocked by a related record is recorded as skipped and kept locally instead of failing every future run.
The per record hash folds in a fingerprint of the mapping definition. Edit a line or a transformer and existing records are rewritten on the next run instead of being skipped as unchanged.
Relational lookups by external id are scoped to the connection in play, so two connections that happen to hold the same external id for the same model never cross bind to each other's record.
The number transformer refuses a grouped value where a comma could be a decimal or a thousands separator rather than risk a 1000x error. The record fails in isolation and is visible and recoverable.
What is inside
Built to do the job, end to end.
- Sync jobs. A job binds an endpoint, a mapping and a target model, plus the policy knobs: direction (pull, push or both), full or delta mode, batch size, inbound conflict policy and outbound push policy. Domain modules ship jobs as data, and an integrator can add or tune them in the UI. Jobs run manually, on a schedule or from a webhook through one orchestrator.
- External id cross reference. A dedicated model links each Odoo record to its platform id per connection, storing the source last modified timestamp and both the inbound and outbound payload hashes. Unique constraints make the link deterministic in both directions, so an Odoo record maps to exactly one external id per connection.
- Field mapping with transformers. Mappings translate one platform resource to one Odoo model, line by line, with optional per company and per country variants. Lines run through a registry of safe transformers: dates and datetimes normalised to UTC, strict number parsing, JSON value maps with a default, relations resolved by field or external id, and sub line arrays turned into One2many commands. Each has a reverse for push.
- Audited runs. Every run records counts (fetched, created, updated, skipped, deleted, failed), timing and a per record line history with the operation and any message. An overview surfaces the last run, its status and its created, updated and failed totals on each job, so a non technical user can see at a glance what each sync did and when.
- Scheduled and webhook triggered. A daily cron runs the jobs flagged as scheduled, behind a master switch in Settings. Webhook triggered runs use the same engine through a targeted single record pull path, so an inbound change to one entity is fetched by id and never re paginates the whole endpoint.
- Dry run and delta. A dry run writes nothing yet still reports what would be created and updated, which powers the preview before a risky change. Delta mode reads only records changed since the last successful run on both the pull and the push side, so a steady state sync does not re scan everything every time.
Honest about the edges
What this does not do, so nothing surprises you.
- This is the engine layer of the suite. On its own it provides the sync jobs, mappings, cross reference and run history, but the actual API connection, OAuth and rate limiting live in the base module, and the concrete jobs and mappings for employees, payroll or recruitment ship in the relevant domain modules.
- Inbound webhook receipt, HMAC signature verification, replay protection and the queue with retry and dead letter handling are provided by the separate webhook module of the suite. This module supplies only the targeted single record sync path those deliveries trigger.
- Rate limit handling, request retry with backoff and OAuth token refresh are handled by the base transport, not here. This engine consumes that transport and does not implement its own HTTP retry policy.
- Synchronisation is configuration driven. It moves data between fields you map, it does not invent business logic, post journal entries or run payroll calculations. Those belong to the domain modules and to Odoo itself.
- The number transformer deliberately refuses ambiguous grouped formats rather than guess. If a source genuinely sends grouped numbers, normalise them at the source or add a locale aware transformer.
- Conflict resolution is timestamp and policy based, not field level merge. When both sides change a record the configured policy decides which whole side wins for that record, it does not merge individual fields.
Employment Hero sync engine, Employment Hero Odoo integration, external id cross reference, idempotent upsert Odoo, configurable field mapping, two way sync Odoo, pull and push synchronisation, conflict resolution policy, delta incremental sync, dry run preview, per record error isolation, audited sync runs, value transformers mapping, multi company sync, HR and payroll synchronisation
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.
A dependency free asynchronous job queue that runs long running and fan out work out of band of the request that...
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...
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
Discuss (mail)
|
| Community Apps Dependencies | Show |
| Lines of code | 3546 |
| Technical Name |
eh_hero_sync |
| 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