Identity and access management
Loket to Ping Identity integration: PingOne users per employer from Loket.nl
With an integration between Loket.nl and Ping Identity, every new employee from Loket gets a user in PingOne, in their employer's population and with their organisational unit as a group. After the end date of the last employment KoppelHet disables the user in PingOne, so the applications behind PingOne close.
What the integration does
Organisations with payroll in Loket.nl, often at a payroll bureau, and PingOne for sign-in have no connection between the two. IT hears about a new colleague by email, creates the PingOne user by hand and only disables it when someone remembers.
- A dedicated Loket user with read-only rights gives KoppelHet consent, and PingOne gets a Worker app with the Identity Data Admin role.
- KoppelHet requests the changed employees and employments per employer and skips drafts.
- For a new employee KoppelHet creates a user in their employer's population, which is enabled on the start date.
- KoppelHet puts the user in their organisational unit's group and moves them on a transfer.
- After the end date of the last employment KoppelHet disables the user and deletes them after the agreed period.
What to watch for with Loket and Ping Identity
- A payroll bureau often manages several employers in Loket, each with its own employee numbers. KoppelHet gives each employer its own population in PingOne and puts the employer code in the external key, so password policy and sign-in rules can differ per employer and numbers do not clash.
- Loket grants access through a user's consent, which is renewed continuously with a refresh token. PingOne works with a Worker app that fetches its own token. KoppelHet manages both, and has the Loket consent given by a dedicated user with read-only rights, so the integration keeps working when someone at the bureau leaves.
- PingOne's SCIM entry point does not manage groups. KoppelHet creates a group per organisational unit from Loket through the regular PingOne API and maintains membership, so application access per department moves along on a transfer.
- A search on PingOne's SCIM entry point returns at most 200 users, without a next page. Loket only reports changes by email and not to systems. KoppelHet therefore requests the changed employees per employer and searches PingOne specifically on the external key, instead of comparing all users.
- In Loket prefix, surname and partner name are stored separately. KoppelHet puts the prefix in front of the surname in the family name in PingOne, so applications behind PingOne show "van Bergen" and do not treat the prefix as a middle name.
- PingOne accepts one email address per user. A new employee often has no business address in Loket yet. KoppelHet creates the address according to the naming rule with the employer's domain, and never puts a private address from Loket in PingOne.
- An employee can first exist in Loket as a draft, and an employment can continue after a gap. KoppelHet only creates a PingOne user once the draft has been converted, and only disables it after the last period of the chain, so a returning employee gets the same user back.
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
Our payroll bureau works in Loket. Is that possible?
Yes, with a dedicated Loket user for the integration that only reads your employers.
Does pay data go to PingOne?
No. Only name, employer, unit, work email 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) per employer through the mutations on employee and employment; fields include employeeNumber, firstName, prefix, lastName, prefixPartner, lastNamePartner, organisational unit and start and end date. Event notifications are email recipients only.
- PingOne through a Worker app with the Identity Data Admin role: users through the SCIM API (/v2/DirectMappedUsers, population.id per employer, externalId, a single email value; search with .search on the key, at most 200 results, no paging), groups and memberships through the PingOne Platform API, disabling through enabled.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Loket | Field in Ping Identity | Notes |
|---|---|---|
Werkgevercode + employeeNumber | externalId | Unique across all employers |
Naamgevingsregel | username | |
firstName | name.given | |
prefix, lastName, prefixPartner, lastNamePartner | name.family | According to name usage, prefix first |
Naamgevingsregel met domein per werkgever | email | |
Werkgever | population.id | |
Organisatorische eenheid | Groep (Platform API) | |
Einddatum laatste dienstverband | enabled = false |
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