Identity and access management
Nmbrs to Ping Identity integration: users in PingOne from payroll
With an integration between Nmbrs and Ping Identity, a new employee from Nmbrs automatically has a user in PingOne, in the population of their Nmbrs company and with department, job and manager. After the end date KoppelHet disables the user, so they can no longer reach the applications behind PingOne.
What the integration does
Organisations that record payroll and HR in Nmbrs and handle sign-in through PingOne have a new colleague in Nmbrs well before the start date. They only reach PingOne when IT gets a request, and leavers keep access until someone disables the user.
- Someone with an employer-level Nmbrs login grants the integration read rights, and PingOne gets a Worker app with admin rights on identity data.
- KoppelHet reads the employees per Nmbrs company with department, job and manager.
- For a new employee KoppelHet creates a user in their company's population, which is enabled shortly before the first working day.
- The user becomes a member of their department's group; when the department changes, the membership moves with it.
- After the end date KoppelHet disables the user and deletes them after the agreed period.
What to watch for with Nmbrs and Ping Identity
- A Nmbrs environment can hold several companies, each with its own employee numbers. KoppelHet gives each company its own population in PingOne and builds the external key from company code and number, so two employees with number 1001 stay two separate users.
- A new employee often has no business email in Nmbrs yet, and PingOne accepts only one email address per user. KoppelHet then fills in the address according to the naming rule and never passes on the private address from Nmbrs.
- PingOne's SCIM entry point does not page and returns at most 200 users. A comparison of all Nmbrs employees with PingOne cannot be done there. KoppelHet keeps its own record of which user belongs to which employee and searches by that key.
- PingOne's SCIM entry point cannot manage groups. KoppelHet creates the groups per department through the regular PingOne API and adds the members there, so application access by department moves with Nmbrs.
- Department and job take effect per payroll period in Nmbrs. KoppelHet moves the user in PingOne to the new group on the first day of that period, not at the moment payroll enters the change.
- Nmbrs holds BSN, salary and bank details. The integration only reads employee data and company structure, and PingOne only receives the fields that sign-in and application access need.
- Nmbrs switches off its SOAP API on 1 March 2027. This integration uses the REST API with an employer-level login, so no later migration is needed.
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 work if Nmbrs runs through an accounting firm?
Yes, with its own employer-level login for the integration. The firm's own login does not work.
What if the manager is not in Nmbrs?
The attribute then stays empty and the platform reports it, so HR can add the manager.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Nmbrs is read through the Nmbrs REST API with OAuth 2.0 and only read scopes for employees and company structure (debtor-level login). The SOAP API is retired from 1 March 2027.
- PingOne is written with a Worker app with the Identity Data Admin role: users through the SCIM API (/v2/DirectMappedUsers, population.id per Nmbrs company, externalId, a single email value; lookups with POST /v2/DirectMappedUsers/.search on the key, at most 200 results), groups and memberships through the PingOne Platform API and disabling through enabled (PATCH may not remove enabled).
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Nmbrs | Field in Ping Identity | Notes |
|---|---|---|
Bedrijfscode + personeelsnummer | externalId | Unique across all companies |
Naamgevingsregel | username | |
Roepnaam | name.given | |
Achternaam volgens naamstelling | name.family | |
Zakelijk e-mailadres of naamgevingsregel | email | |
Functie (omschrijving) | title | |
Afdeling | Groep en eigen attribuut afdeling | |
Leidinggevende | Eigen attribuut leidinggevende | |
Nmbrs-bedrijf | population.id | |
Datum uit dienst | enabled |
Related
ADP Workforce Now → Nmbrs
ADP Workforce Now to Nmbrs integration: the Dutch payroll group from ADP in the right Nmbrs company
AlexisHR → Nmbrs
AlexisHR (Simployer One) to Nmbrs integration: Dutch employees into payroll
BambooHR → Nmbrs
BambooHR to Nmbrs integration: Dutch payroll next to a global HR system
Bullhorn → Nmbrs
Bullhorn to Nmbrs integration: placements with hourly pay and end date in payroll