Nmbrs logoX4

HR to ITSM

Nmbrs to Xurrent integration: people per entity and requests from a template in Xurrent (4me)

With an integration between Nmbrs and Xurrent (formerly 4me), every employee from your Nmbrs companies is a person in Xurrent, in the organisation of their entity and department, with job title and manager. On a new employment, a change per payroll period or an end date KoppelHet creates a request from your Xurrent template, and after the last working day the person is disabled.

What the integration does

Organisations with several entities in Nmbrs and a service desk in Xurrent often add people with a periodic import or SCIM from the identity provider. Anyone without an account yet is missing there, and which entity someone belongs to for charging hardware is recorded nowhere.

  1. Payroll enters the employee at the right Nmbrs company.
  2. Once the work email is known, KoppelHet creates the person in their department's organisation, under their entity's business unit.
  3. Within the agreed lead time before the start date the onboarding request follows from the template, for the new person.
  4. A change per the next payroll period gives a request with the first day of that period as desired completion date.
  5. On an end date the offboarding request follows; after the last working day the person is disabled.
Nmbrs → KoppelHet → Xurrent (4me)SOURCENmbrsTARGETXurrent (4me)Xurrent (4me)KoppelHetmapping · logging · monitoringNmbrs → KoppelHet → Xurrent (4me)SOURCENmbrsTARGETXurrent (4me)Xurrent (4me)KoppelHetmapping · logging · monitoring
Out: Person with company code and employee number, name, work email and job title · Company as business unit, departments as organisations below it · Manager of the person · Request from a template on joining, leaving and on a change · Disabled person after departure

What to watch for with Nmbrs and Xurrent (4me)

  • Each entity in Nmbrs becomes a business unit in Xurrent, with that entity's departments as organisations below it. Because departments in Nmbrs belong to a company, a Service department of entity A never merges with that of entity B, and Xurrent reports can be made per entity.
  • Xurrent does not store a person without an email address, and payroll often enters a new employee before IT knows the work email. KoppelHet therefore holds the person until the business address is in Nmbrs; meanwhile the onboarding request is submitted by the manager, so IT does not have to wait.
  • Nmbrs keeps a cost centre per payroll period. Xurrent has a field on an organisation for the financial code. KoppelHet fills it with the department's cost centre, so charging hardware per entity uses the same code as the payroll journal.
  • Employee numbers in Nmbrs are unique per company. KoppelHet puts company code and number together in Xurrent's employeeID, and records Nmbrs as the source, so an import from another system recognises these people and does not overwrite them.
  • When a former employee returns under the same Nmbrs number, KoppelHet re-enables the existing person in Xurrent instead of creating a new one. Their earlier requests and configuration items thus stay with them.
  • An import in Xurrent that only matches on email address overwrites all fields of that person. If employees are already there through such an import or through SCIM, KoppelHet links them once by work email, has you check the list and then switches to the Nmbrs number.
  • A job change per the next period is already in Nmbrs before it takes effect. KoppelHet creates the request straight away, but with the first day of that period as desired completion date, so IT prepares access in time and does not change it too early.

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, architecture and compliance

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.

Price indication · Basic

Leave your work email and you see the price indication right away.

We only use your address to follow up on your question about this integration.

Frequently asked questions

Can we keep SCIM from Entra ID?

Yes, if we agree per field which source wins. Nmbrs then supplies entity, department, cost centre and dates; the identity provider the account.

Do pay or BSN go to Xurrent?

No. The integration only reads personal, employment and organisation data.

Our accounting firm manages Nmbrs. What do they notice?

They create an employer-level login once and grant consent for your companies. Nothing after that.

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 employee and employment data and the company structure, per company; webhooks on changes. The SOAP API stops on 1 March 2027.
  • Xurrent through the REST API with an OAuth token and the X-Xurrent-Account header. People through /people (primary_email required, employeeID, job_title, organization, manager, disabled, source and sourceID), organisations through /organizations (parent, business_unit, financialID, manager). The token never gets more rights than the integration account's roles.
  • Requests through POST /requests with requested_for, requested_by, subject, category, team and template, plus desired_completion_at and custom_fields for the template's UI extension.

Which fields are transferred

The key fields. The full mapping is agreed per customer.

Field in NmbrsField in Xurrent (4me)Notes
Bedrijfscode + personeelsnummeremployeeID en sourceID (source Nmbrs)Numbers in Nmbrs are only unique per company
Voornaam, tussenvoegsel en achternaamname
Zakelijk e-mailadresprimary_emailRequired in Xurrent
Functie (huidige periode)job_title
Bedrijforganization met business_unit
Afdeling (huidige periode)organization met het bedrijf als parent
KostenplaatsfinancialID van de organisatie
Leidinggevende (e-mailadres)manager van de person
Indiensttreding, wissel of vertrekRequest met template, requested_for en desired_completion_at
Datum uit dienst verstrekendisabled = true

Related

Which systems do you want to connect?

Tell us which systems you use and what should happen automatically. Together we define the smallest working solution, with a clear design and a quote before building.