HR to ERP
HiBob to Oracle Fusion ERP integration: employees from Bob in Oracle, ready for expenses and approvals
With an integration between HiBob and Oracle Fusion ERP, every employee from Bob appears in Oracle automatically, with business unit, department, manager and default expense account. A change HR schedules ahead in Bob is in Oracle with the same effective date, so approvals move to the new manager on that day.
What the integration does
Organisations that manage their people in HiBob and use Oracle Fusion for finance put new employees into Oracle by hand or with a spreadsheet. Bob is already updated after a reorganisation, but in Oracle the old manager keeps approving expenses for weeks.
- HR adds an employee in Bob or schedules a work change; Bob sends a webhook.
- KoppelHet reads the work history with a service user that only sees the fields it needs, and translates department and entity into Oracle values.
- KoppelHet builds a load file with the periods from Bob and loads it into Oracle with HCM Data Loader.
- Rejected lines go to HR or finance, with the reason from Oracle.
- After the departure in Bob the work relationship in Oracle gets an end date.
What to watch for with HiBob and Oracle Fusion ERP
- A line in Bob's work history only has an effective date. Oracle wants a start and end date per period. KoppelHet ends each period on the day before the next line in Bob, so Oracle gets no overlapping assignments.
- When HR schedules a change ahead in Bob, the webhook for the new history line arrives straight away, not only on the effective date. KoppelHet loads that change into Oracle straight away with the future date, so the approval route switches on the right day.
- In Bob the department is a value from a list, and the API returns that value's ID. Oracle looks up the department by name. KoppelHet translates the list ID through Bob's lists API into the name that exists as a department in Oracle.
- A reference to the manager only works in HCM Data Loader with a source key from the same owner. KoppelHet therefore loads new managers from Bob first and then their reports, both with the Bob ID as source key.
- Oracle does not let anyone without a default expense account submit an expense report. Bob has no ledger account; KoppelHet derives it from entity and cost centre in Bob with a finance table, and reports an employee without a cost centre instead of guessing an account.
- The service user in Bob only gets permissions on the fields Oracle needs, with history access for the work table. If that history access is missing, Bob reports the columns as restricted; KoppelHet then stops with an alert instead of loading periods without a department.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Does salary from Bob go to Oracle?
No. The service user gets no salary permissions. It is not needed for expenses and approvals.
Can departments also be created in Oracle automatically?
That can be added later as an extension. In the first version the department must exist in Oracle and KoppelHet reports what is missing.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- HiBob through employee data webhooks (table.entry.created, table.entry.updated, employee.left) and the work history per employee (effectiveDate, department, site, reportsTo); list values through the lists API; restricted_columns with no_view_permission and no_view_history_permission.
- To Oracle through HCM Data Loader (Worker.dat with Worker, PersonName, PersonEmail, WorkRelationship, WorkTerms, Assignment with BusinessUnitId, DepartmentName, LocationCode and DefaultExpenseAccount, and AssignmentSupervisor), with SourceSystemOwner from HRC_SOURCE_SYSTEM_OWNER. Load status through the HCM Data Loader web service or REST.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in HiBob | Field in Oracle Fusion ERP | Notes |
|---|---|---|
root.id | SourceSystemId | With its own owner for Bob in the lookup |
firstName, surname en work.email | PersonName en PersonEmail | |
Entiteit | Legal employer en BusinessUnitId | Through a table |
work.department | DepartmentName | List ID translated to name |
work.site | LocationCode | |
work.reportsTo | AssignmentSupervisor | |
Entiteit + kostenplaats | DefaultExpenseAccount | |
Werkhistorie effectiveDate | EffectiveStartDate en EffectiveEndDate |
Related
Ashby → HiBob
Ashby to HiBob integration: a hire from Ashby straight in as an employee in Bob
Bullhorn → HiBob
Bullhorn to HiBob integration: an approved placement as a new employee in Bob
Carerix → HiBob
Carerix to HiBob integration: successful match becomes a new employee in Bob
Greenhouse → HiBob
Greenhouse to HiBob integration: from a hire in Greenhouse to a new employee in Bob