HR naar ITSM
Keka koppelen met ServiceNow: medewerkers als gebruiker en verzoeken op het moment dat een exit is goedgekeurd
Met een koppeling tussen Keka en ServiceNow wordt elke medewerker uit Keka een gebruiker in ServiceNow, met functie, afdeling, locatie en manager, en bestelt KoppelHet een catalogusitem voor onboarding bij een nieuwe medewerker en voor offboarding zodra Keka een exit goedkeurt. Keka meldt die momenten met een webhook, en ServiceNow krijgt de gegevens via de Import Set API en de Service Catalog API.
Wat de koppeling doet
Organisaties die Keka gebruiken voor HR en ServiceNow voor IT, krijgen een goedgekeurde exit in Keka vaak pas te horen als de medewerker zijn laptop komt inleveren. Nieuwe collega's verschijnen in ServiceNow pas na de eerste synchronisatie met de directory.
- In Keka zet HR onder Event Triggers een webhookactie op nieuwe medewerker, goedgekeurde exit en geannuleerde exit.
- KoppelHet controleert de geheime header, haalt de medewerker op via de Keka API en zet hem in de staging table van ServiceNow.
- De transform map maakt of werkt de gebruiker bij op personeelsnummer, met afdeling, locatie en manager.
- Bij een nieuwe medewerker bestelt KoppelHet het onboardingitem; bij een goedgekeurde exit het offboardingitem met de exitdatum.
- Elk uur haalt KoppelHet ook alles op wat sinds de vorige ronde in Keka is gewijzigd, voor wijzigingen zonder event.
Waar je op let bij Keka en ServiceNow
- Keka kent naast de directe manager ook een L2-manager en een dotted-line manager. Het managerveld van een gebruiker in ServiceNow neemt er één; KoppelHet zet daar reportsTo in, zodat goedkeuringen in de catalogus bij de directe leidinggevende landen.
- Het offboardingitem wordt besteld op het event van een goedgekeurde exit, en dat ligt meestal weken voor de exitdatum. De servicedesk heeft dan de hele opzegtermijn om terugname van apparatuur en overdracht van mailboxen te plannen.
- HR kan in Keka een goedgekeurde exit nog annuleren. Op dat event zet KoppelHet een werknotitie op het openstaande offboarding-RITM en meldt het aan de toewijzingsgroep, zodat accounts niet alsnog worden uitgezet.
- Keka houdt bij of iemand op de vaste lijst staat of een contingent worker is. KoppelHet bestelt voor contingent workers een lichter catalogusitem, zonder laptop en met een einddatum op de toegang.
- Keka stuurt in de webhook een identificatie en het soort event, zonder handtekening. KoppelHet laat Keka een eigen geheime header meesturen en zet in ServiceNow alleen gegevens die het daarna zelf uit de Keka API heeft opgehaald.
- Keka geeft geen kantoor als apart veld, wel een plaats en een landcode. Bij de start leggen we vast welke combinatie bij welke cmn_location hoort; de transform map zoekt de locatie daarop op.
- De Keka API staat vijftig aanroepen per minuut toe en geeft maximaal 200 medewerkers per pagina. De uurronde vraagt alleen wijzigingen op via lastModified, zodat ook een organisatie met duizenden medewerkers binnen die grens blijft.
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 als iemand vertrekt zonder dat de exit via Keka is goedgekeurd?
Dan vangt de uurronde het op: een exitdatum of de status Relieved in Keka levert alsnog een offboardingverzoek op.
Gaan salaris of persoonlijke gegevens naar ServiceNow?
Nee. Keka levert die velden wel, maar de transform map neemt alleen naam, werkmail, functie, groep, plaats, manager en de datums over.
Technische details voor IT
Voor wie wil weten hoe het onder de motorkap werkt: gebruikte API's, velden en bronnen.
- Keka API (https://{bedrijf}.keka.com/api/v1) met een OAuth-token van login.keka.com (scope kekaapi). GET /hris/employees met lastModified, employmentStatus (Working, Relieved), inNoticePeriod en pageSize (maximaal 200); velden employeeNumber, email, jobTitle, groups, reportsTo, l2Manager, dottedLineManager, city, countryCode, workerType, contingentType, joiningDate, exitDate en exitReason. Webhooks via Settings > Communications > Event Triggers met optionele eigen headers. Limiet vijftig verzoeken per minuut.
- Naar ServiceNow via de Import Set API (POST /api/now/import/{stagingTableName}/insertMultiple) met transform maps en coalesce op employee_number; met run_after eerst cmn_department en cmn_location, daarna sys_user. Verzoeken via POST /api/sn_sc/servicecatalog/items/{sys_id}/order_now met variabelen en sysparm_requested_for; werknotities op het RITM via de Table API.
Welke velden overgaan
De belangrijkste velden. De volledige mapping stellen we per klant vast.
| Veld in Keka | Veld in ServiceNow | Toelichting |
|---|---|---|
employeeNumber | employee_number | Coalesce-veld |
firstName, lastName, displayName | first_name, last_name | |
email | email | |
jobTitle | title | |
groups (afdeling) | department (cmn_department) | |
city + countryCode | location (cmn_location) | |
reportsTo | manager (sys_user) | |
joiningDate | Variabele startdatum op het onboardingitem | |
exitDate en exitReason | Variabelen op het offboardingitem | |
workerType / contingentType | Keuze van het catalogusitem |
Gerelateerd
Keka → Active Directory
Keka koppelen met Active Directory: domeinaccounts per vestiging, met vervaldatum op de exit
Keka → ADP iHCM
Keka ADP iHCM koppeling: salarisopbouw, variabele uitbetalingen en vertrek van de Nederlandse pay group naar ADP
Keka → AFAS Profit
Keka koppelen met AFAS: Nederlandse medewerkers uit Keka in de salarisadministratie
Keka → Arbodienst (SIVI)
Keka koppelen met de arbodienst via SIVI: leave requests voor ziekte als verzuimmelding