Identity and access management
ADP iHCM to Omada integration: ADP iHCM as the authoritative source for Omada Identity
With an integration between ADP iHCM and Omada Identity, Omada reads the employees from iHCM as identities, with department, country and manager, so roles, reviews and revoking access run on ADP's data. Omada has no ADP connector, but the REST collector can read ADP's Worker API; KoppelHet sets up that import and monitors it.
What the integration does
Organisations that run payroll and HR in several European countries with ADP iHCM and Omada for identity governance often load an export from ADP into Omada. Who makes that export and when depends on the payroll calendar, so a departure sometimes reaches Omada weeks after the last working day.
- ADP adds the Worker API for your iHCM environment to the integration's application registration.
- In Omada we create a REST system for identity data with ADP's credentials.
- We configure the query with paging per hundred, the selection of the primary work assignment and a filter on the countries that belong in Omada.
- We map identities, contexts and owners and set thresholds.
- After each import KoppelHet compares the counts with ADP and reports deviations.
What to watch for with ADP iHCM and Omada
- Omada has no ADP connector in the Connectivity Directory or the documentation. The iHCM Worker API does fit Omada's REST collector, so Omada can read iHCM without an intermediate layer. KoppelHet sets up that import and does not build its own copy of the data next to it.
- iHCM returns at most one hundred employees per call and gives an error for a higher value. The end is an empty list. Omada's REST collector can page with URL parameters and a counter, and keeps reading until an empty result if no total is given. KoppelHet sets $skip to that counter and $top to one hundred.
- The iHCM Worker API does not support filtering on work assignment, so a selection by country cannot go into the call to ADP. Omada has a filter expression per query that returns true or false per row. KoppelHet puts the countries that belong in Omada there, so the rest of the group stays out of the import.
- An employee can have several work assignments in iHCM. With an alias in Omada, a JSON path with a condition, KoppelHet selects the assignment with primaryIndicator set to true, so department and owner come from the main job and not from the first assignment in the response.
- Not every employee in iHCM has an associateOID, ADP writes; the workerID is always there. Omada requires a unique business key per identity. KoppelHet therefore uses the workerID, so no employee comes in without a key and a rehire lands on the existing identity.
- Without a status filter iHCM also returns employees who are no longer employed, with their leaving date. Omada can therefore set an end date instead of seeing an identity disappear. Omada picks up a moved last working day at the next import, since iHCM has no separate notification for it.
- In iHCM 'Reports to' and supervisor exist side by side; ADP sends leave requests to 'Reports to'. KoppelHet makes 'Reports to' the owner of the identity in Omada, so access reviews sit with the same manager who also approves leave.
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 does ADP need to arrange?
ADP opens the Worker API for your environment in the application registration and provides the credentials. Without that step Omada gets no data.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- ADP iHCM Worker Management API: GET /hr/v2/workers?$skip={index}&$top=100 (at most 100, end at an empty workers list or 204), no filters on WorkAssignment, optional status filter workers/workerStatus/statusCode/codeValue eq 'current'; fields workerID/idValue, associateOID, person/legalName, workerDates, workAssignments (primaryIndicator, homeOrganizationalUnits, homeWorkLocation, reportsTo). Access after being added in the Consumer Application Registry (CAR).
- Omada REST collector (Content: Identity data): OAuth2 Client Credentials with token endpoint and scope, optional Include certificate with certificate and private key in PEM; paging URL parameters without Total; alias mappings with a JSONPath condition on primaryIndicator; filter expression on country code; required identity mapping Business key, Unique ID, Name and Status; thresholds per import.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in ADP iHCM | Field in Omada | Notes |
|---|---|---|
workerID (Employee Reference Number) | Business key en Unique ID | Not every employee has an associateOID |
person.legalName | Name, FirstName, LastName | |
businessCommunication.email | Email | |
workerStatus en workerDates.terminationDate | Status, ValidTo | |
workerDates (hire) | ValidFrom | |
workAssignments (primaryIndicator): homeOrganizationalUnits | Context (afdeling) en context assignment | |
workAssignments (primaryIndicator): reportsTo | Identity owner | |
homeWorkLocation.address.countryCode | Country (extensieattribuut) |
Related
ADP iHCM → Active Directory
ADP iHCM to Active Directory integration: network accounts per country, with an expiry date for temporary contracts
ADP iHCM → Coupa
ADP iHCM to Coupa integration: approved Coupa expenses as a variable pay field in ADP iHCM NL
DyADP iHCM → Dyflexis
ADP iHCM to Dyflexis integration: employees and contracts in scheduling, hours back to ADP
ADP iHCM → Microsoft Entra ID
ADP iHCM to Entra ID integration: accounts from ADP payroll, with the right licence in every European country