HaHR to ITSM
Loket HaloITSM integration: employers as sites, employees as users and tickets on joining and leaving
With an integration between Loket and HaloITSM, every employee from Loket becomes a user in Halo, on the site of their employer and with department and job, and KoppelHet creates an onboarding ticket for a new employment and an offboarding ticket before it ends. After the last day the integration sets the user in Halo to inactive.
What the integration does
Organisations with several employers in Loket and HaloITSM as their service desk often maintain the users in Halo with an export from the directory. Whoever has no account yet is not in Halo, and a departure only shows once the account has already been closed.
- KoppelHet fetches the changes in employees and employments per employer.
- Each employer from Loket has its own site in Halo; the user goes on their employer's site.
- For a new employment KoppelHet creates the user and an onboarding ticket on the ticket type for new employees.
- For an end of employment an offboarding ticket follows with the reason from Loket.
- After the last day KoppelHet sets the user to inactive.
What to watch for with Loket and HaloITSM
- In Halo a user always sits under a site. KoppelHet creates a site for each employer from Loket, so an engineer can see from the site which employer a colleague works for.
- Halo has a department field, but Loket manages departments per employer. Two departments with the same name at different employers stay apart in Halo because they are on different sites.
- The Loket employee number is only unique within one employer. KoppelHet stores employer and number together in a custom field on the Halo user and looks the user up on that.
- An onboarding ticket in Halo must belong to a user. KoppelHet therefore creates the user immediately for a new employment, even if Loket has no business email yet, and adds the address later.
- The reason for leaving from Loket goes into a custom field on the offboarding ticket. A workflow in Halo can then block accounts straight away for a dismissal and wait until the last day for an expiring contract.
- Halo allows 700 calls per 300 seconds per tenant and returns a 429 above that. KoppelHet therefore spreads the initial load with all employers from Loket over several minutes.
- Loket can only email people on an event, not call another system. KoppelHet therefore fetches the changes itself, a few times a day per employer.
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
Does this also work with HaloPSA or HaloServiceDesk?
The API is the same. This page assumes HaloITSM with one client and a site per employer.
Our payroll runs through an accounting firm. Can the integration still work?
Yes. Someone with access to your employers in Loket gives the integration permission once.
Does salary data go to Halo?
No. Only name, business email, job, department, employer, dates and the reason for leaving.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Loket through the Loket REST API with OAuth 2.0 (authorization code flow with refresh token), per employer. Employee with employeeNumber, firstName, prefix, lastName and businessEmailAddress; employment with start date, endDate and endOfEmploymentReason; departments per employer through /providers/employers/{employerId}/departments.
- Halo through the Halo REST API with an API application (client credentials). POST /Users with site_id, department, title, emailaddress and customfields; inactive on departure. POST /Tickets with tickettype_id, user_id, site_id, summary, details and customfields. Rate limit of 700 calls per 300 seconds per tenant, HTTP 429 above that.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Loket | Field in HaloITSM | Notes |
|---|---|---|
Werkgever + employeeNumber | Eigen veld (customfields) | Key, unique across all employers |
firstName, prefix, lastName | name | |
businessEmailAddress | emailaddress | |
Werkgever | site_id | |
Afdeling | department | |
Functie | title | |
Begindatum dienstverband | Ticket met tickettype_id onboarding | |
endDate en endOfEmploymentReason | Ticket met tickettype_id offboarding, customfields | |
Einddatum verstreken | inactive |
Related
ADP Workforce Now → Loket
ADP Workforce Now to Loket integration: hires, pay, hours and bonuses from ADP to the Dutch payroll run
AlexisHR → Loket
AlexisHR to Loket integration: employees of the Dutch company from AlexisHR into payroll
BambooHR → Loket
BambooHR to Loket integration: HR changes from BambooHR for Dutch payroll
Bullhorn → Loket
Bullhorn to Loket integration: placement as a concept employee in the right payroll administration