Identity and access management
ADP iHCM to Ping Identity integration: employees from ADP iHCM as users in PingOne
With an integration between ADP iHCM and Ping Identity, every new employee from iHCM gets a user in PingOne, in the population of their country and with job title, work email and manager. PingOne has no ADP source; KoppelHet processes ADP's notifications about joining and leaving, delivers the users through PingOne's SCIM entry point and disables them on the leaving date.
What the integration does
Organisations that run HR and payroll in several European countries with ADP iHCM and PingOne for single sign-on and MFA often put new colleagues into PingOne by hand or with a bulk file. Anyone who leaves between two files keeps access until the next file, and a name change after a marriage gets stuck in PingOne.
- ADP adds the Worker API and the notifications for KoppelHet to the application registration of your iHCM environment.
- In PingOne the administrator creates a Worker app with the Identity Data Admin role and a population per country.
- KoppelHet reads all employees once and then processes ADP's notifications.
- A new employee becomes a disabled user who is enabled on the joining date; a leaver is disabled on their leaving date.
- Every day KoppelHet checks per employee whether PingOne matches iHCM and reports differences.
What to watch for with ADP iHCM and Ping Identity
- PingOne only has Workday as an inbound HR source; beyond that an LDAP gateway and SCIM. Advanced Identity Cloud has no ADP template either. KoppelHet uses PingOne's SCIM API, which Ping recommends for importing users.
- Filtering on work assignment is not possible in the iHCM Worker API, so not on country either. KoppelHet fetches the employees and then chooses the population of the work location's country per employee, so MFA and password policy can differ per country.
- A rehire arrives at ADP as an ordinary hire notification. KoppelHet first searches PingOne on the workerID as externalId. If the user still exists, KoppelHet enables it again instead of creating a second one, so the returning colleague keeps their MFA registration.
- ADP reports a name change separately. In PingOne the username is fixed once PingID is in the environment. KoppelHet therefore updates given and family name, but not the username; a new login name after a name change is a deliberate step by IT.
- PingOne accepts only one email address per user, and PingOne also uses that address for recovery and notifications. iHCM reports the business and the private address with separate notifications. KoppelHet only processes the notification for the business address, so a private address never ends up in PingOne.
- ADP sends the departure notification again when the date or reason changes, and also when a departure is withdrawn; a separate notification for just the date does not exist. KoppelHet reschedules the disabling in PingOne on every notification to the current date, and removes the schedule if the departure is cancelled.
- An employee can have a 'Reports to' and a supervisor in iHCM. PingOne has no standard field for the manager. KoppelHet puts 'Reports to' in a custom attribute, because ADP also sends leave requests there, so apps behind PingOne can follow the same line.
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 and the notifications for your environment in the application registration. Without that step no data or notifications arrive.
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 with $skip and $top (at most 100), per person on associateOID or workerID; no filters on WorkAssignment. Notifications worker.hire (also return), worker.terminate (also changed date or reason), worker.legalName.change, worker.businessCommunication.email.change and worker.workAssignment.modify; access through the Consumer Application Registry (CAR).
- PingOne through a Worker app with the Identity Data Admin role: SCIM /v2/Users with externalId (search with eq), userName (unique, fixed with PingID), one email value, title, active and population.id in the PingOneUser extension; lists up to 200 without paging; changing population through PUT /users/{id}/population; manager as a custom attribute of type string.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in ADP iHCM | Field in Ping Identity | Notes |
|---|---|---|
workerID (Employee Reference Number) | externalId | |
person.legalName | name.givenName, name.familyName | |
Naamgevingsregel | userName | Does not change with the name |
businessCommunication.email | emails (één waarde) | |
workAssignments (primair): jobTitle | title | |
homeWorkLocation.address.countryCode | population.id | |
reportsTo ('Reports to') | Manager (eigen attribuut) | |
workerDates (hire, termination) | active (enabled) |
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