AFAS Profit logoIvanti logo

HR to ITSM

AFAS to Ivanti integration: employees from AFAS Profit as employees in Ivanti Neurons for ITSM, with service requests for joiners and leavers

With an integration between AFAS Profit and Ivanti Neurons for ITSM, every employee from AFAS is an employee in Ivanti, with department, job title, employer and manager, and KoppelHet submits a service request from your published template on every hire, transfer or departure. The choices HR records in AFAS, such as a laptop or only an account, are answered questions in that request.

What the integration does

Organisations that run HR and payroll in AFAS and their service desk in Ivanti Neurons for ITSM often maintain the employees in Ivanti with an import from Active Directory or by hand. A new colleague then only exists in Ivanti once IT has created their account, while that account is the very first request.

  1. HR completes the AFAS workflow for the new employee, with the choices for laptop, phone and access in free fields.
  2. KoppelHet reads the employee with a dedicated connector and creates the employee in Ivanti, or updates it on employee number.
  3. Within the agreed lead time before the start date, KoppelHet submits the onboarding request, in the new employee's name.
  4. A different department or job results in a change request; an end date in an offboarding request one week ahead.
  5. After the last working day KoppelHet sets the employee in Ivanti to inactive.
AFAS Profit → KoppelHet → IvantiSOURCEAFAS ProfitTARGETIvantiKoppelHetmapping · logging · monitoringAFAS Profit → KoppelHet → IvantiSOURCEAFAS ProfitTARGETIvantiKoppelHetmapping · logging · monitoring
Out: Employee with employee number, name, work email and job title · Department and employer from AFAS · Manager of the employee · Onboarding service request from a published template, with the choices from AFAS · Service request on transfer and on departure

What to watch for with AFAS Profit and Ivanti

  • Ivanti only creates a service request for an employee who already exists, because the request needs the customer's RecID and a template that is available to that person. KoppelHet therefore first stages the employee once the AFAS workflow is completed, and only then submits the onboarding request.
  • Free fields in AFAS such as laptop or phone become answers to template questions in Ivanti. If such a question is a pick list, Ivanti expects the internal code of the chosen value. KoppelHet records per free field which value in the Ivanti list matches, and flags an AFAS value that is missing there.
  • AFAS arranges organisational units as a tree. The department on an employee in Ivanti is a value from a validation list. KoppelHet picks the unit per employee at the level your service desk uses, and flags a new unit from AFAS that does not yet exist as a value in Ivanti.
  • An AFAS environment with several employers can have the same employee number at two employers when numbering runs per employer. KoppelHet then puts the employer in front of the number, so Ivanti keeps two different employees.
  • If a new employment in AFAS follows directly on the previous one, the employee in Ivanti stays active and no offboarding request follows. Only when department or job changes does a change request appear.
  • Ivanti returns at most one hundred records per query. In the first run KoppelHet therefore compares the AFAS file in blocks with the employees in Ivanti, and links existing employees once by work email before the employee number becomes the key.
  • AFAS dates apply to a Dutch calendar day. Ivanti asks for the offset from UTC in minutes on a service request. KoppelHet passes it with each request, also around the switch to summer time, so a start date does not shift by a day.

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

Do salary data or BSN go to Ivanti?

No. The AFAS connector only contains the fields the service desk needs.

Do we need to set anything up in Ivanti?

Yes: a published template for onboarding, change and offboarding, and a REST API key for an integration user with only the rights on employees and service requests.

Technical details for IT

For those who want to know how it works under the hood: APIs, fields and sources used.

  • AFAS is read with dedicated GetConnectors (employees with employment and free fields, organisational units, employers) under its own app connector, filtered on modification date. No BSN, salary or private address. The classic token expires on 31 August 2027.
  • Ivanti is written through the OData REST API on /api/odata/businessobject/employees: POST to create, PATCH on the RecID to update, $filter and $top (default 25, maximum 100) to search. Validated fields have a matching _Valid field with the RecID of the list value. Authorisation with a REST API key in the Authorization header (rest_api_key=…), created in a dedicated key group on behalf of an integration user with its own role.
  • Service requests through POST /api/rest/ServiceRequest/new with subscriptionId (from api/rest/Template/{employee RecID}/_All_), strUserId and strCustomerLocation, parameters keyed par-{RecID} (pick lists also with -recId from the ValidationList) and localOffset in minutes. All fields from the example are mandatory. KoppelHet stores per employee which request was submitted per event.

Which fields are transferred

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

Field in AFAS ProfitField in IvantiNotes
MedewerkernummerPersoneelsnummer op de employeeFixed key; KoppelHet stores Ivanti's RecID with it
Roepnaam, voorvoegsel en achternaamVoornaam en achternaam van de employee
E-mail werkE-mailadres en loginnaam
FunctieFunctietitel
Organisatorische eenheidAfdelingValue from Ivanti's validation list
WerkgeverLocatie of eigen veld voor de werkgever
LeidinggevendeManager van de employee
Datum uit dienstStatus inactief na de laatste werkdag
Indiensttreding, overplaatsing of vertrekServiceverzoek uit het sjabloon (subscriptionId)
Vrije velden laptop, telefoon en toegangParameters van het sjabloon (par-…)

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.