HR to ITSM
Keka ServiceNow integration: employees as users and requests the moment an exit is approved
With an integration between Keka and ServiceNow, every employee from Keka becomes a user in ServiceNow, with job title, department, location and manager, and KoppelHet orders a catalog item for onboarding when a new employee is added and for offboarding as soon as Keka approves an exit. Keka signals those moments with a webhook, and ServiceNow receives the data through the Import Set API and the Service Catalog API.
What the integration does
Organisations that use Keka for HR and ServiceNow for IT often only hear about an approved exit in Keka when the employee comes to hand in their laptop. New colleagues only appear in ServiceNow after the first directory sync.
- In Keka, HR sets a webhook action under Event Triggers on employee added, exit approved and exit cancelled.
- KoppelHet checks the secret header, fetches the employee through the Keka API and puts them in the ServiceNow staging table.
- The transform map creates or updates the user on employee number, with department, location and manager.
- For a new employee KoppelHet orders the onboarding item; for an approved exit the offboarding item with the exit date.
- Every hour KoppelHet also fetches everything that changed in Keka since the previous run, for changes without an event.
What to watch for with Keka and ServiceNow
- Besides the direct manager, Keka also knows an L2 manager and a dotted-line manager. The manager field of a user in ServiceNow takes one; KoppelHet puts reportsTo there, so catalog approvals land with the direct manager.
- The offboarding item is ordered on the event of an approved exit, which is usually weeks before the exit date. The service desk then has the whole notice period to plan collecting equipment and handing over mailboxes.
- HR can still cancel an approved exit in Keka. On that event KoppelHet adds a work note to the open offboarding RITM and notifies the assignment group, so accounts are not switched off anyway.
- Keka records whether someone is on the regular payroll or a contingent worker. For contingent workers KoppelHet orders a lighter catalog item, without a laptop and with an end date on the access.
- Keka sends an identifier and the event type in the webhook, without a signature. KoppelHet has Keka send a custom secret header and only puts data in ServiceNow that it then fetched itself from the Keka API.
- Keka has no office as a separate field, only a city and a country code. At the start we record which combination belongs to which cmn_location; the transform map looks up the location on that.
- The Keka API allows fifty calls per minute and returns at most 200 employees per page. The hourly run only asks for changes through lastModified, so even an organisation with thousands of employees stays within that limit.
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 if someone leaves without the exit being approved in Keka?
Then the hourly run catches it: an exit date or the status Relieved in Keka still produces an offboarding request.
Does salary or personal data go to ServiceNow?
No. Keka does supply those fields, but the transform map only takes name, work email, job title, group, city, manager and the dates.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Keka API (https://{company}.keka.com/api/v1) with an OAuth token from login.keka.com (scope kekaapi). GET /hris/employees with lastModified, employmentStatus (Working, Relieved), inNoticePeriod and pageSize (at most 200); fields employeeNumber, email, jobTitle, groups, reportsTo, l2Manager, dottedLineManager, city, countryCode, workerType, contingentType, joiningDate, exitDate and exitReason. Webhooks through Settings > Communications > Event Triggers with optional custom headers. Limit of fifty requests per minute.
- ServiceNow is written through the Import Set API (POST /api/now/import/{stagingTableName}/insertMultiple) with transform maps and coalesce on employee_number; with run_after first cmn_department and cmn_location, then sys_user. Requests through POST /api/sn_sc/servicecatalog/items/{sys_id}/order_now with variables and sysparm_requested_for; work notes on the RITM through the Table API.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Keka | Field in ServiceNow | Notes |
|---|---|---|
employeeNumber | employee_number | Coalesce field |
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 |
Related
Keka → Active Directory
Keka to Active Directory integration: domain accounts per office, with expiry on the exit date
Keka → ADP iHCM
Keka to ADP iHCM integration: salary structure, variable payouts and leavers of the Dutch pay group to ADP
Keka → AFAS Profit
Keka to AFAS integration: Dutch employees from Keka in payroll
Keka → Arbodienst (SIVI)
Keka to the occupational health service via SIVI: sickness leave requests as absence reports