Identity en access management
ADP iHCM Omada koppeling: ADP iHCM als gezaghebbende bron voor Omada Identity
Met een koppeling tussen ADP iHCM en Omada Identity leest Omada de medewerkers uit iHCM als identiteiten, met afdeling, land en leidinggevende, zodat rollen, reviews en het intrekken van toegang op de gegevens van ADP draaien. Omada heeft geen ADP-connector, maar de REST-collector kan de Worker API van ADP lezen; KoppelHet richt die import in en bewaakt hem.
Wat de koppeling doet
Organisaties die salaris en personeel in meerdere Europese landen met ADP iHCM regelen en Omada voor identity governance, laden vaak een export van ADP in Omada. Wie die export maakt en wanneer, hangt af van de salariskalender, waardoor een vertrek soms pas weken na de laatste werkdag in Omada aankomt.
- ADP voegt de Worker API voor jullie iHCM-omgeving toe aan de applicatieregistratie van de koppeling.
- In Omada maken we een REST-systeem voor identiteitsdata met de aanmeldgegevens van ADP.
- We stellen de query in met paginering per honderd, de keuze van de primaire werktoewijzing en een filter op de landen die in Omada horen.
- We koppelen identiteiten, contexten en eigenaren en stellen drempels in.
- Na elke import vergelijkt KoppelHet de aantallen met ADP en meldt afwijkingen.
Waar je op let bij ADP iHCM en Omada
- Omada heeft geen connector voor ADP in de Connectivity Directory of de documentatie. De Worker API van iHCM past wel bij de REST-collector van Omada, zodat Omada iHCM zonder tussenlaag kan lezen. KoppelHet richt die import in en bouwt geen eigen kopie van de gegevens ernaast.
- iHCM geeft hooguit honderd medewerkers per aanroep en geeft een fout bij een hogere waarde. Het einde is een lege lijst. De REST-collector van Omada kan pagineren met URL-parameters en een teller, en leest door tot een leeg resultaat als er geen totaal is opgegeven. KoppelHet zet $skip op die teller en $top op honderd.
- Filteren op werktoewijzing ondersteunt de Worker API van iHCM niet, dus een selectie op land kan niet in de aanroep naar ADP. Omada heeft per query een filterexpressie die per regel waar of onwaar teruggeeft. KoppelHet zet daar de landen in die in Omada horen, zodat de rest van de groep buiten de import blijft.
- Een medewerker kan in iHCM meerdere werktoewijzingen hebben. Met een alias in Omada, een JSON-pad met een voorwaarde, kiest KoppelHet de toewijzing met primaryIndicator op true, zodat afdeling en eigenaar uit de hoofdfunctie komen en niet uit de eerste toewijzing in het antwoord.
- Niet iedere medewerker in iHCM heeft een associateOID, schrijft ADP; het workerID is er wel altijd. Omada vraagt een unieke business key per identiteit. KoppelHet gebruikt daarom het workerID, zodat geen medewerker zonder sleutel binnenkomt en een herindiensttreding op de bestaande identiteit landt.
- Zonder statusfilter geeft iHCM ook medewerkers die niet meer in dienst zijn, met hun vertrekdatum. Omada kan zo een einddatum zetten in plaats van een identiteit te zien verdwijnen. Een verschoven laatste werkdag pakt Omada bij de volgende import op, want iHCM heeft daar geen eigen melding voor.
- In iHCM bestaan 'Reports to' en supervisor naast elkaar; ADP stuurt verlofaanvragen naar 'Reports to'. KoppelHet maakt 'Reports to' de eigenaar van de identiteit in Omada, zodat reviews van toegang bij dezelfde leidinggevende liggen die ook het verlof goedkeurt.
Deze koppeling hoort ook bij in-, door- en uitstroom.
Hoe we het bouwen en beheren
- De koppeling draait op het KoppelHet platform, gehost in een datacenter in de EU.
- Elke synchronisatie en elke fout is zichtbaar in de functionele logging; bij een fout krijgt jullie beheerder een melding.
- Een mutatie die niet door kan, wordt niet half doorgezet maar klaargezet om opnieuw te proberen.
- KoppelHet is ISO 27001-gecertificeerd. Gegevens gaan versleuteld over en blijven niet langer op het platform dan nodig.
- Na livegang beheren wij de koppeling en passen we hem aan als jullie proces verandert.
- De koppeling past naast je bestaande integratielaag. Alleen de velden uit het ontwerp gaan over; het platform houdt geen eigen registratie bij.
Implementatie en prijs
Dit is geen app die je aanzet. We bouwen de koppeling voor jullie organisatie op ons platform, met bouwstenen die we steeds opnieuw gebruiken. Zo is het maatwerk, zonder dat we bij nul beginnen.
Een consultant bereidt de intake voor en analyseert beide systemen. Daarna leggen we de mapping en uitzonderingen per veld vast, testen we in de test- of acceptatieomgeving en gaan we live op een moment dat jij kiest. De kosten bestaan uit een eenmalig bedrag voor de inrichting en een maandbedrag voor platform, monitoring en beheer.
Veelgestelde vragen
Wat moet ADP regelen?
ADP zet de Worker API voor jullie omgeving open in de applicatieregistratie en levert de aanmeldgegevens. Zonder die stap krijgt Omada geen gegevens.
Technische details voor IT
Voor wie wil weten hoe het onder de motorkap werkt: gebruikte API's, velden en bronnen.
- ADP iHCM Worker Management API: GET /hr/v2/workers?$skip={index}&$top=100 (maximaal 100, einde bij een lege workers-lijst of 204), geen filters op WorkAssignment, statusfilter workers/workerStatus/statusCode/codeValue eq 'current' optioneel; velden workerID/idValue, associateOID, person/legalName, workerDates, workAssignments (primaryIndicator, homeOrganizationalUnits, homeWorkLocation, reportsTo). Toegang na toevoeging in de Consumer Application Registry (CAR).
- Omada REST-collector (Content: Identity data): OAuth2 Client Credentials met token endpoint en scope, optioneel Include certificate met certificaat en privésleutel in PEM; paginering URL parameters zonder Total; alias mappings met JSONPath-voorwaarde op primaryIndicator; filterexpressie op landcode; verplichte identiteitsmapping Business key, Unique ID, Name en Status; drempels per import.
Welke velden overgaan
De belangrijkste velden. De volledige mapping stellen we per klant vast.
| Veld in ADP iHCM | Veld in Omada | Toelichting |
|---|---|---|
workerID (Employee Reference Number) | Business key en Unique ID | Niet elke medewerker heeft een 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) |
Gerelateerd
ADP iHCM → Active Directory
ADP iHCM Active Directory koppeling: netwerkaccounts per land, met vervaldatum bij tijdelijke contracten
ADP iHCM → Coupa
ADP iHCM Coupa koppeling: goedgekeurde onkosten uit Coupa als variabel looncomponent in ADP iHCM NL
DyADP iHCM → Dyflexis
ADP iHCM Dyflexis koppeling: medewerkers en contracten in de planning, uren terug naar ADP
ADP iHCM → Microsoft Entra ID
ADP iHCM Entra ID koppeling: accounts uit de ADP-payroll, in elk Europees land met de juiste licentie