HR to ITSM
Keka to TOPdesk integration: persons, departments and contingent workers from Keka, with tickets at hire and approved exit
With an integration between Keka and TOPdesk, every employee from Keka is a person in TOPdesk, with department, job, city and manager, and the service desk gets a ticket for every new employee and every approved exit. KoppelHet responds to Keka's event triggers and then fetches the employee through the API.
What the integration does
Organisations that use Keka, often with a team in India and an office in the Netherlands, have the Dutch service desk work in TOPdesk. An approved exit then sits in Keka, while the service desk hears through an email from HR that a laptop has to come back.
- HR adds the employee in Keka with department, job, city and manager.
- The event trigger sends a webhook. KoppelHet fetches the employee and creates the person in TOPdesk if they belong to a branch of this service desk.
- Four weeks before the joining date an onboarding ticket reaches the branch's operator group.
- After an exit is approved an offboarding ticket arrives with the exit date as target date.
- If the exit is cancelled, the ticket gets an addition and the person stays active. If the exit goes ahead, the person is archived after the exit date.
What to watch for with Keka and TOPdesk
- Keka only makes an exit final after approval, and HR can still cancel it afterwards. KoppelHet creates the offboarding ticket on the event for an approved exit, and adds a note to that ticket on a cancelled exit, so the service desk does not collect a laptop from someone who stays.
- Keka's webhook only contains the employee's identifier, the event type and the subdomain, and no signature. KoppelHet gives the webhook its own secret header and then fetches the employee itself, so a ticket never enters TOPdesk because of an unknown call.
- Keka provides the worker type for every employee and whether someone is a contingent worker. KoppelHet puts that in the category of the onboarding ticket, so a contingent worker with their own laptop only gets accounts.
- Keka can filter employees on who is in their notice period. In the hourly run KoppelHet requests that group separately, so a departure recorded without an event still gets an offboarding ticket.
- The exit date comes from Keka as a date with time, often recorded in Indian time. KoppelHet converts it to the Dutch date before it becomes target date and end date in TOPdesk.
- Keka has no field for a branch, only a city and country code. At the start KoppelHet maps every combination of city and country to a branch in TOPdesk; employees outside those combinations stay out of TOPdesk.
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
Do colleagues from India also end up in TOPdesk?
Only if this service desk serves them. Which cities and countries are included is set at the start.
What if an event trigger does not arrive?
Keka does not describe webhook retries. The hourly run on lastModified and the request for those in their notice period catch a missed event.
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 a token from login.keka.com/connect/token (scope kekaapi). GET /hris/employees with lastModified, employmentStatus (Working, Relieved), inNoticePeriod and pageSize (default 100, at most 200); fields employeeNumber, email, jobTitle, groups, reportsTo, city, countryCode, workerType, contingentType, joiningDate, exitDate and exitStatus. Event triggers through Settings > Communications > Event Triggers with a webhook action (form fields employeeIdentifier, eventType, subDomain and optional custom headers), including employee added, exit approved and exitCancelled. Limit of fifty requests per minute.
- TOPdesk is written through the TOPdesk REST API with an application password: persons through Supporting Files (employeeNumber at most 20 characters, archiving with a reason), incidents with POST /tas/api/incidents (callerLookup, briefDescription, category, operatorGroup, targetDate, externalNumber).
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Keka | Field in TOPdesk | Notes |
|---|---|---|
employeeNumber | employeeNumber | |
firstName en lastName | firstName en surName | |
email | email | |
jobTitle.title | jobTitle | |
groups (groupType afdeling) | department | |
city en countryCode | branch | |
reportsTo | manager | |
workerType en contingentType | Categorie van de melding | |
joiningDate | hireDate en targetDate van de onboardingmelding | |
exitDate | employmentTerminationDate en targetDate van de offboardingmelding |
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