OIIdentity and access management
ADP iHCM to One Identity integration: ADP iHCM as the HR source for One Identity Manager
An integration between ADP iHCM and One Identity Manager prepares employees, departments and managers from iHCM in fixed files, which One Identity Manager's CSV connector reads as Person and Department. One Identity has no connector for iHCM; KoppelHet reads iHCM through ADP's Worker API and keeps leaving dates and rehires up to date in the file.
What the integration does
Organisations that run payroll and HR in several European countries with ADP iHCM and One Identity Manager for accounts and permissions often receive new colleagues through an export from ADP. That export only contains who is employed at that moment, so One Identity Manager does not see a leaver leave but only sees them disappear.
- ADP adds the Worker API and the notifications for KoppelHet to the application registration of your iHCM environment.
- KoppelHet reads all employees in batches of one hundred and then processes the notifications about joining, leaving and work assignment.
- KoppelHet prepares an employee file and a department file in a folder the One Identity Manager synchronisation server reads.
- One Identity Manager reads the departments first and then the employees with the CSV connector.
- KoppelHet checks every set of files before the synchronisation starts and reports missing fields.
What to watch for with ADP iHCM and One Identity
- Through Starling Connect One Identity Manager has HR connectors for Workday, SuccessFactors and Dayforce among others, but not for ADP iHCM. The CSV connector comes standard with One Identity Manager and needs no extra subscription. That is why KoppelHet delivers the iHCM data as a file, in a shape fixed in the synchronisation project.
- Not every employee in iHCM has an associateOID, ADP itself says; then the workerID is the way to request someone. KoppelHet uses the workerID as the key column for One Identity Manager, so no employee enters the file without a key and the CSV connector never has to choose between duplicate rows.
- The iHCM Worker API does not support filtering on work assignment. KoppelHet therefore cannot ask ADP for a selection by country or entity, but makes it after fetching. Only employees of the countries that belong in One Identity Manager go into the file.
- ADP reports a rehire with the same notification as a new employee. Because the workerID stays the same, the returning colleague appears in the file under the same key with a new joining date. One Identity Manager then picks up the existing Person again instead of creating a second one.
- iHCM has no separate notification for a changed leaving date; ADP sends the departure notification again when the date or reason changes. KoppelHet reads the current date on every departure notification, so ExitDate in the file moves and One Identity Manager revokes permissions on the right day.
- In iHCM an employee can have both a 'Reports to' and a supervisor. ADP sends leave requests to 'Reports to'; the supervisor is for recording only. KoppelHet puts 'Reports to' in the manager column, so attestations in One Identity Manager end up with the same person as the leave requests.
- Because the files come from another source, the synchronisation in One Identity Manager runs as a data import, and then a missing employee cannot be marked as outstanding. KoppelHet therefore does not remove leavers from the file but keeps them with their ExitDate, until after the period you keep accounts for.
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 do?
ADP adds the Worker API and the notifications to the application registration of your environment. Without that step the API returns 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 through the Worker Management API: GET /hr/v2/workers with $skip and $top (at most 100, an error above that; end at an empty workers list or 204), per person on associateOID or workerID; no filters on WorkAssignment. Notifications worker.hire (also on return), worker.terminate (also on changed date or reason; worker.workerTerminationDate.change not supported), worker.legalName.change, worker.businessCommunication.email.change and worker.workAssignment.modify. APIs and notifications only after being added in the Consumer Application Registry (CAR).
- One Identity Manager CSV connector: system connection with an employee file and a department file, UTF-8 with header row and text qualifiers, key column per file, Hierarchical sort order on the department path, Uniqueness violation behavior set to Throw error, Read-only access, synchronisation step as Data import (no MarkAsOutstanding), through a remote connection server if needed.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in ADP iHCM | Field in One Identity | Notes |
|---|---|---|
workerID (Employee Reference Number) | Sleutelkolom PersonnelNumber | Also when an employee has no associateOID |
legalName (voornaam, achternaam) | FirstName, LastName | |
workAssignments.jobTitle | Kolom functie | |
homeOrganizationalUnits | Afdelingspad (hiërarchische sortering) | |
reportsTo ('Reports to') | Kolom manager (PersonnelNumber) | |
homeWorkLocation.address.countryCode | Kolom land | |
workerDates (hire, termination) | EntryDate, ExitDate | Always YYYY-MM-DD |
businessCommunication.email | Kolom zakelijk e-mailadres |
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