Nmbrs logoIvanti logo

HR to ITSM

Nmbrs to Ivanti integration: employees per company as employees in Ivanti Neurons for ITSM, with service requests for joiners and leavers

With an integration between Nmbrs and Ivanti Neurons for ITSM, every employee from your Nmbrs companies is an employee in Ivanti, with company, department, job and manager, and KoppelHet submits a service request from the Ivanti template on a new employment, a job change or a departure. Anyone who returns under the same employee number becomes the same employee in Ivanti again, reactivated.

What the integration does

Organisations that run payroll in Nmbrs, often through an accounting firm, and have their service desk in Ivanti Neurons for ITSM only hear about a new colleague when the manager remembers. With several entities Ivanti does not show which operating company someone belongs to, and leavers remain active employees there.

  1. Payroll enters the new employee at the right company in Nmbrs.
  2. Nmbrs reports the change; KoppelHet fetches employee, employment, job and department and creates the employee in Ivanti.
  3. Within the agreed lead time before the start date the onboarding request follows in the new employee's name.
  4. A job or department change per the next period is applied on the first day of that period, with a change request.
  5. On an end date the offboarding request is submitted, and after the last working day the employee becomes inactive.
Nmbrs → KoppelHet → IvantiSOURCENmbrsTARGETIvantiKoppelHetmapping · logging · monitoringNmbrs → KoppelHet → IvantiSOURCENmbrsTARGETIvantiKoppelHetmapping · logging · monitoring
Out: Employee with company and employee number, name, work email and job · Department per company · Manager · Service request for onboarding, change and offboarding · Inactive employee after departure, active again on return

What to watch for with Nmbrs and Ivanti

  • Employee numbers in Nmbrs are unique per company, so two entities can both have a number 15. KoppelHet puts the company code in front of the number on the employee in Ivanti, so a search on employee number always returns one person.
  • A department in Ivanti is a value from one list for the whole environment; in Nmbrs each company has its own department list. If Purchasing exists at two entities, KoppelHet makes two values with the company added, so assignment and reporting per entity are correct.
  • Nmbrs records job and department per payroll period. KoppelHet updates the employee in Ivanti on the first day of that period and passes that day as the start date of the change request, so access does not change at the moment payroll types it.
  • When a former employee returns, Nmbrs gives them a new employment under the same number. KoppelHet looks up the existing employee in Ivanti and sets it back to active, so earlier requests and assigned equipment stay with the same person; the onboarding request refers to that employee.
  • Nmbrs knows the manager's name and email address. KoppelHet uses that address to look up the employee in Ivanti and sets them as manager, even when the manager is employed by another entity.
  • The end date is often only fixed in Nmbrs when the final payroll is prepared. If that date is already within a week, KoppelHet submits the offboarding request in Ivanti straight away instead of on the fixed lead time.
  • If payroll runs through an accounting firm, the firm gives the integration access to only your companies with an employer-level login. Ivanti therefore gets no data from the firm's other clients, and the firm does not need to pass anything on to IT.

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

Our accounting firm manages Nmbrs. What do they need to do?

Create an employer-level login once and grant consent for your companies. After that the firm notices nothing of the integration.

Do pay or BSN go to Ivanti?

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

What if a new employee has no work email yet?

Then KoppelHet stages the employee without a login name and fills it in once the address is in Nmbrs. The onboarding request does not wait for it.

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.
  • Ivanti is written through the OData REST API (/api/odata/businessobject/employees, POST and PATCH on RecID; $filter on email address for the manager; $top at most 100). Validated fields with _Valid. REST API key in the Authorization header (rest_api_key=…).
  • Service requests through POST /api/rest/ServiceRequest/new with subscriptionId from the published templates, strUserId (employee RecID), strCustomerLocation, parameters par-{RecID} and localOffset.

Which fields are transferred

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

Field in NmbrsField in IvantiNotes
Bedrijfscode + personeelsnummerPersoneelsnummer op de employeeNumbers in Nmbrs are only unique per company
Voornaam, tussenvoegsel en achternaamVoornaam en achternaam
Zakelijk e-mailadresE-mailadres en loginnaam
Functie (huidige periode)Functietitel
Afdeling (huidige periode)Afdeling, met het bedrijf erbij als de naam vaker voorkomt
BedrijfLocatie of eigen veld voor het bedrijf
Leidinggevende (e-mailadres)Manager van de employee
Datum in dienstParameter startdatum van het onboardingverzoek
Datum uit dienstOffboardingverzoek en status inactief

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.