X4HR to ITSM
Loket Xurrent integration: people per employer organization and requests on joining and leaving
With an integration between Loket and Xurrent, every employee from Loket becomes a person in Xurrent, in the organization of their employer, and KoppelHet creates a request on the right template for a new employment and before it ends. After the last day the integration sets the person in Xurrent to disabled.
What the integration does
Organisations with several employers in Loket and Xurrent as their service management platform often load people into Xurrent from the directory. A new colleague only exists there after their first working day, and the onboarding request is submitted by someone copying the data from Loket.
- KoppelHet fetches the changes in employees and employments per employer from Loket.
- For a new employment KoppelHet creates a request on the onboarding template, in the name of that employer's fixed HR requester as long as there is no email address.
- Once Loket has a business email, KoppelHet creates or updates the person in the employer's organization.
- For an end of employment a request follows on the offboarding template, with the reason from Loket.
- After the last day KoppelHet sets the person to disabled.
What to watch for with Loket and Xurrent (4me)
- A person in Xurrent must have a primary email address, which is also their login name. A new employee without a business address in Loket cannot be a person yet; KoppelHet then raises the onboarding request in the name of a fixed HR requester per employer, with the new colleague in the text, and creates the person later.
- Each employer from Loket becomes an organization in Xurrent, under one parent organization for the group. Teams and service contracts in Xurrent can thus differ per employer.
- Xurrent has a source and a source ID per person to show which system a record comes from. KoppelHet fills in Loket and the combination of employer and employee number there; only the Account Administrator role may do that, so the integration's token has that role.
- Loket restarts the numbering per employer. Because the employee number in Xurrent is meant to be unique, KoppelHet puts the employer code in front of it.
- A request in Xurrent has a desired completion date. KoppelHet puts the start date from Loket there, so the service desk in Xurrent sees which onboarding must be ready first.
- After the last day KoppelHet sets the person to disabled instead of archiving them. Their earlier requests and configuration items stay linked to them, while new links are no longer possible.
- A concept employee in Loket produces nothing in Xurrent yet. Only once the concept is a real employee with an employment does KoppelHet create the onboarding request.
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 works for two employers in Loket?
Then it stays one person in Xurrent, in the organization of the main employment. Which one that is, we agree during the intake.
Does salary data go to Xurrent?
No. Only name, business email, job title, 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; concepts through /conceptemployees.
- Xurrent through the REST API: /organizations (parent), POST and PATCH /people (primary_email required and unique, organization, manager, job_title, employeeID, disabled, source and sourceID; source only by an Account Administrator). Requests through POST /requests with category, subject, requested_by, requested_for, team, template and desired_completion_at.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Loket | Field in Xurrent (4me) | Notes |
|---|---|---|
Werkgever + employeeNumber | employeeID en sourceID | Unique across all employers |
firstName, prefix, lastName | name | |
businessEmailAddress | primary_email | |
Functie | job_title | |
Werkgever | organization | |
Begindatum dienstverband | desired_completion_at op het onboardingrequest | |
endDate en endOfEmploymentReason | Offboardingrequest (template, note) | |
Einddatum verstreken | disabled = true |
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