Loket logoFreshservice logo

HR to ITSM

Loket to Freshservice integration: employees per employer as requesters, requests on joining and leaving

With an integration between Loket and Freshservice, every employee from Loket becomes a requester in Freshservice, with the right employer and department, and KoppelHet submits an onboarding request for a new employment and an offboarding request before it ends. Loket itself sends no messages to other systems and Freshservice has no Loket connector, so KoppelHet fetches the changes per employer and turns them into requesters and requests.

What the integration does

Organisations that use Loket for payroll and Freshservice for ICT questions often learn about new and departed employees through a monthly list from the payroll bureau. Until that list arrives, new colleagues have no account and departed substitutes can still log in.

  1. The payroll bureau records a new employee and the employment in Loket.
  2. KoppelHet fetches the changes per employer since the previous run.
  3. Freshservice receives an onboarding request with start date, job, department and employer. As soon as the business email is in Loket, the employee also becomes a requester.
  4. A different department or job in Loket updates the requester.
  5. Before the end of employment an offboarding request arrives with the reason; after the last day the requester is deactivated.
Loket → KoppelHet → FreshserviceSOURCELoketTARGETFreshserviceKoppelHetmapping · logging · monitoringLoket → KoppelHet → FreshserviceSOURCELoketTARGETFreshserviceKoppelHetmapping · logging · monitoring
Out: Requester with name, business email and job · Employer as location, department as department · Onboarding request with start date · Offboarding request with reason for end of employment · Deactivation after the last day

What to watch for with Loket and Freshservice

  • Loket can only email people on an event; it has no message to another system. KoppelHet therefore asks per employer a few times a day what has changed in Loket, and turns that into a requester or a request in Freshservice.
  • A requester in Freshservice needs an email address or phone number. A new employee often has no business email in Loket yet, because IT creates it later. KoppelHet therefore submits the onboarding request by name first, and creates the requester as soon as the business address is in Loket.
  • Loket numbers employees per employer, so two employers can both have an employee 1012. The external ID of a requester in Freshservice is meant for SCIM from an identity provider. KoppelHet stores the combination of employer and number in a custom field on the requester.
  • Loket records a reason at the end of an employment. KoppelHet puts that reason in the separation type of the offboarding form, so Freshservice chooses a different kit for a dismissal than for a contract expiring.
  • Substitutes and on-call workers often get a temporary employment in Loket with an end date already known at the start. KoppelHet only submits the offboarding request shortly before that date, and skips it if Loket adds a follow-on employment.
  • Each employer in Loket has its own list of departments. Freshservice has one list for the whole account. Two employers with a department North therefore become two departments with the employer in the name, and the employer itself becomes the requester's location.
  • A new employee can first exist in Loket as a concept. By default KoppelHet waits until the concept is converted, so no onboarding request arrives for someone who has not been hired yet; more preparation time is possible by starting at the concept stage.

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 payroll runs through an accounting firm. Can the integration still work?

Yes. Someone with access to your employers in Loket gives the integration permission once. That can be someone at the firm or in your own HR team.

Does salary data go to Freshservice?

No. Only name, business email, job, department, employer and the employment dates. Salary, citizen service number and home address stay in Loket.

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 with OAuth 2.0 (authorization code flow), per employer. Employee with employeeNumber, firstName, prefix, lastName and businessEmailAddress; employment with start date, endDate and endOfEmploymentReason; departments through /providers/employers/{employerId}/departments and concepts through /conceptemployees. Event notifications in Loket are email recipients only.
  • Freshservice is written through the Freshservice API v2: requesters (primary_email, work_phone_number or mobile_phone_number required; department_ids, location_id and custom_fields), POST /api/v2/onboarding_requests and /api/v2/offboarding_requests with form fields such as cf_date_of_joining and cf_separation_type. external_id is a number for SCIM and stays empty.

Which fields are transferred

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

Field in LoketField in FreshserviceNotes
Werkgever + employeeNumberEigen aanvragersveld (custom_fields)Unique across all employers
firstName, prefix en lastNamefirst_name en last_namePrefix with the surname
businessEmailAddressprimary_email
Functie van het dienstverbandjob_title
Afdeling (departments per werkgever)department_ids
Werkgeverlocation_id
Begindatum dienstverbandOnboardingverzoek (cf_date_of_joining)
endDate en endOfEmploymentReasonOffboardingverzoek (cf_separation_type)
Einddatum verstrekenrequester deactiveren

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.