Identity and access management
Loket to Omada integration: employees from Loket.nl as identities in Omada Identity, per employer
With an integration between Loket.nl and Omada Identity, Omada reads every employee from Loket as an identity, with employer and organisational unit as context and a status that follows from the employment. KoppelHet manages the consent at Loket and offers one record per employee that Omada's REST collector reads directly, without pay or bank data.
What the integration does
Organisations that have their payroll in Loket.nl, often through a payroll bureau, and manage access with Omada usually get employees into Omada through an export. That export follows the payslip rather than the organisation, and a payroll bureau running the export for several employers sometimes delivers a file missing one employer's employees.
- A dedicated Loket user with read-only rights on your employers gives KoppelHet one-time consent.
- KoppelHet reads the employees, employments and organisational units per employer.
- KoppelHet offers three collections on its own secured address, identities, contexts and context assignments.
- Omada's REST collector reads that address with OAuth2 Client Credentials and Omada assigns roles by context.
- After the end of the last employment the status becomes terminated and Omada revokes access.
What to watch for with Loket and Omada
- Loket grants access through the consent of a Loket user, with an authorization code and a refresh token. Omada's REST collector supports client credentials and a password flow among others, but not that authorization code. KoppelHet manages the consent at Loket and offers Omada its own address with client credentials.
- Besides identities, Omada can also import contexts, each with a key, name and type, and assignments of identities to those contexts. KoppelHet turns every Loket employer and every organisational unit into a context, so roles and ownership in Omada can work per employer and department.
- An employee number in Loket is only unique within one employer. Omada requires a unique key per identity; KoppelHet puts the employer code in front of the number, so employees of two employers at the same payroll bureau never merge into one identity.
- Employments in Loket are a chain of periods, sometimes with a gap between them. Omada has the statuses active, inactive and terminated. KoppelHet sets an employee in a gap between two periods to inactive and only to terminated after the last period, so a returning employee keeps their identity and history in Omada.
- An employee can first exist in Loket as a draft, as an applicant not yet converted. KoppelHet only includes converted employees in what Omada reads, so an offer that falls through does not produce an identity that sets roles and approvals in motion.
- If the payroll bureau's Loket user loses its rights on one employer, all of that employer's employees are suddenly missing. The threshold on deleted objects is off by default in Omada. We switch that threshold on, and KoppelHet delivers no collection if an employer that had employees yesterday now comes back empty.
- Loket only sends notifications about changes by email to people. KoppelHet therefore requests the recorded changes per employer, so the collection Omada imports shows that morning's state at every scheduled import.
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
Can Omada not sign in to Loket itself?
Loket works with a user's consent, and that method is not among the options of the REST collector. KoppelHet takes over that part.
Does this work if our payroll bureau works in Loket?
Yes. The integration gets its own Loket user with read-only rights on your employers.
Does payroll data go to Omada?
No. Only name, number, employer, unit, job and the status from the employment.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Loket is read through the Loket REST API (oauth.loket.nl, authorization code and refresh token; no client credentials) under /v2/providers/employers/{employerId}/employees, the employments with start and end date and the organisational units; pagination with pageNumber and pageSize. Event notifications are email recipients only. No BSN, pay or bank data in the output.
- Omada reads through the REST collector with OAuth2 Client Credentials. Identities with Business key, Unique ID, Name and Status; contexts with Business key, Name and Type; context assignments with Context business key and Identity UID. Status in Enterprise Server has active, inactive and terminated; Thresholds for new, modified and deleted objects (default 0, off).
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Loket | Field in Omada | Notes |
|---|---|---|
Werkgevercode + employeeNumber | Business key en Unique ID | Required for identities |
firstName, prefix en lastName volgens naamgebruik | Name | Required |
Begin- en einddatum in de keten van dienstverbanden | Status | Derived by KoppelHet |
Werkgever | Context (Business key, Name, Type werkgever) | |
Organisatorische eenheid | Context (Business key, Name, Type afdeling) | |
Werkgever en eenheid van de werknemer | Contexttoewijzing (Context business key, Identity UID) | |
Functie | Identiteitsattribuut functie |
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