Identity and access management
Oracle HCM to Omada integration: Oracle HCM Cloud as the authoritative source for Omada Identity
With an integration between Oracle HCM Cloud and Omada Identity, every employee from Oracle becomes an identity in Omada, with department and legal employer as context and the line manager as owner, so roles and reviews run on HR data. Omada has no connector for Oracle HCM Cloud; KoppelHet prepares one row per person from the primary work relationship, which Omada's REST collector imports.
What the integration does
Organisations that use Oracle HCM Cloud worldwide and Omada for roles and certifications find no Oracle HCM in Omada's connector list. Omada's Oracle connector is about accounts in Oracle systems, not about HR as a source. What remains is a monthly report from Oracle, in which a transfer between legal employers shows up as a departure and a new hire.
- In Oracle we create an integration user with read rights on the employee feeds and on workers, work relationships and assignments.
- KoppelHet reads all persons once and then follows the feeds for hires, changes, terminations and cancellations.
- Per person KoppelHet prepares one row with the data of the primary work relationship and assignment.
- In Omada we create a REST system for identity data that reads the rows as identities, contexts and owners.
- After each import KoppelHet compares the counts with Oracle and reports deviations.
What to watch for with Oracle HCM Cloud and Omada
- Omada's connector list and documentation have no connector for Oracle HCM Cloud. Omada's Oracle connector sheet describes requesting, provisioning and reviewing access in Oracle systems; HR as an authoritative source is not part of it. For Oracle HCM we therefore use the REST collector with content Identity data.
- In Oracle assignments sit under work relationships, which sit under the person. A nested call in Omada's REST collector only uses the first element of a list, and costs an extra call per row. A second work relationship would then silently drop out. KoppelHet selects the primary relationship and assignment itself and delivers one flat row per person.
- On a transfer to another legal employer Oracle creates a new work relationship, while the PersonNumber stays the same. If Omada uses that number as business key, the identity keeps its history and reviews. KoppelHet only changes the employer context, so Omada sees the transfer as a change and not as a departure plus hire.
- Oracle reports a hire as soon as HR records it with a future start date. KoppelHet puts that person in the rows with ValidFrom on the start date, so Omada knows the identity but only lets roles apply from the first working day.
- If a candidate drops out before the start, Oracle sends a separate cancellation of the work relationship. KoppelHet gives that identity a status in Omada showing it never started. Omada warns that a status from the HR source can overwrite a status set in Omada; we agree with you which side leads.
- Oracle's employee feeds fire for employees, contingent workers and pending workers. Whether contractors get roles in Omada is a choice per organisation. KoppelHet puts the worker type as an extension attribute in the row, so role rules in Omada can treat contractors differently from permanent staff.
- A reorganisation in Oracle with one effective date can change hundreds of departments at once. In Omada the thresholds per import are zero by default, so off. KoppelHet sets thresholds for new, modified and deleted objects, so an error in the Oracle structure first triggers an alert instead of a wave of revoked roles.
This integration is also part of joiner, mover, leaver.
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
What happens to employees with two work relationships?
Omada gets one identity with the data of the primary relationship. If the primary relationship changes in Oracle, the context in Omada changes with it.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Oracle HCM Cloud through the employee Atom feeds (newhire, empassignment, empupdate, termination, cancelworkrelship) and the workers resource with workRelationships (PrimaryFlag, LegalEmployerName), assignments (DepartmentName, JobName) and managers; paging with offset and limit.
- Omada REST collector (Content: Identity data) with OAuth2 Client Credentials to the KoppelHet endpoint; required identity mapping Business key, Unique ID, Name and Status; contexts with Business key, Name and Type (department, employer), context assignments with Identity UID, identity owners with Owner UID; thresholds per import; timeout 3600 seconds by default.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Oracle HCM Cloud | Field in Omada | Notes |
|---|---|---|
PersonNumber | Business key en Unique ID | Stays the same on transfer |
names (FirstName, LastName, KnownAs) | Name, FirstName, LastName | |
emails (werk) | Email | |
Status van de arbeidsrelatie en TerminationDate | Status, ValidTo | |
StartDate (arbeidsrelatie) | ValidFrom | |
DepartmentName (primaire assignment) | Context (afdeling) en context assignment | |
LegalEmployerName | Context (werkgever) | |
Lijnmanager (managers) | Identity owner | |
WorkerType | EmploymentType (extensieattribuut) |
Related
Ashby → Oracle HCM Cloud
Ashby to Oracle HCM integration: an accepted offer on an opening becomes a pending worker
Bullhorn → Oracle HCM Cloud
Bullhorn to Oracle HCM integration: an approved placement of an employee becomes a pending worker
Carerix → Oracle HCM Cloud
Carerix to Oracle HCM integration: successful placement as a pending worker in Oracle HCM Cloud
Greenhouse → Oracle HCM Cloud
Greenhouse to Oracle HCM integration: accepted offer as a pending worker in Oracle HCM Cloud