HiBob logoFreshservice logo

HR to ITSM

HiBob to Freshservice integration: requesters and onboarding and offboarding requests from Bob

With an integration between HiBob and Freshservice, every new employee in Bob becomes a requester in Freshservice with department, location and manager, and KoppelHet submits an onboarding request weeks before the start date and an offboarding request before the last working day. Freshworks has its own HiBob connector in beta with recipes for onboarding and offboarding; KoppelHet comes in when job changes, sites in several countries, immediate revocation of access or read-only rights in HiBob are also needed.

What the integration does

Anyone who uses Bob for HR and Freshservice as IT service desk often fills in the onboarding form by hand, sometimes twice because the start date moves. With a departure on garden leave, IT only hears about it after the first day without access has already passed.

  1. HR creates a new employee in Bob with start date, department, site and manager.
  2. HiBob reports the new employee; KoppelHet fetches the details and creates the requester in Freshservice, in the language and time zone of the site.
  3. KoppelHet submits the onboarding request on behalf of the manager, so Freshservice selects the right items from the onboarding kit.
  4. A new department or job updates the requester and produces a service request for access and workplace.
  5. On a termination an offboarding request arrives with the last working day; after that day KoppelHet deactivates the requester.
HiBob → KoppelHet → FreshserviceSOURCEHiBobTARGETFreshserviceKoppelHetmapping · logging · monitoringHiBob → KoppelHet → FreshserviceSOURCEHiBobTARGETFreshserviceKoppelHetmapping · logging · monitoring
Out: Requester with name, work email, job, language and time zone · Department and location from the department and site in Bob · Manager as reporting manager and as initiator of the request · Onboarding request with start date · Offboarding request with separation type, and deactivation after the last working day

What to watch for with HiBob and Freshservice

  • Freshservice's HiBob connector requires a service user that may create, edit and terminate employees. KoppelHet only needs read access to the fields the service desk uses, so an error in the integration can never change HR data in Bob.
  • The connector's onboarding recipe stops when the employee already exists in Freshservice. Someone who moves to an office in another country or returns after a year therefore gets no request. KoppelHet looks at the site and the new start date in Bob and submits a request for the workplace anyway.
  • HiBob has a notification for revoking access immediately, which fires when HR chooses this on a termination. KoppelHet then creates an offboarding request with high priority straight away, instead of waiting until midnight after the last working day.
  • Garden leave counts as a departure in HiBob as soon as it starts, even if the contract ends later. The offboarding request then arrives on the first day of the garden leave, so laptop and access do not remain until the formal end date.
  • The connector's ticket widget can show the home address and home phone from Bob to agents. KoppelHet only sends work data to Freshservice; private data stays in HiBob.
  • HiBob processes employees per site, in that site's time zone. Freshservice has its own time zone and language per requester. KoppelHet fills these from the site in Bob, so a colleague in another time zone sees notifications and the portal in their own time and language.
  • Long-term leave with the choice to remain active produces no departure notification in HiBob. The requester then stays active in Freshservice, so the employee can raise a ticket as soon as they return.

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 HR's onboarding tasks stay in HiBob?

Yes. Welcome email and documents stay in Bob's onboarding. The request in Freshservice covers laptop, accounts and workplace.

What happens if the start date moves in Bob?

KoppelHet remembers which request has already been submitted and does not submit a second one. KoppelHet reports the new date to the service desk, so it can adjust the existing request.

Technical details for IT

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

  • HiBob is read through webhooks (employee events v2: employee.created, employee.updated, employee.left, employee.inactivated and employee.access.revoked.immediately). A notification only contains the employeeId and, on an update, the IDs of changed fields; KoppelHet then fetches the employee through people search. Lifecycle events fire at midnight after the effective date in the site's time zone.
  • Freshservice is written through the Freshservice API v2: requesters (create, update, deactivate; with department_ids, location_id, reporting_manager_id, time_zone, language and custom_fields), POST /api/v2/onboarding_requests and /api/v2/offboarding_requests with initiator_id and form fields, and place_request for a catalog item on a job change. external_id in Freshservice is a number for SCIM from an identity provider, so we do not use it.
  • Freshservice limits the number of calls per minute per plan, from 100 on Starter to 500 on Enterprise. We spread the first load of all requesters over that limit.

Which fields are transferred

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

Field in HiBobField in FreshserviceNotes
root.idEigen aanvragersveld (custom_fields)Fixed key; external_id stays free for SCIM from Entra ID or Okta
root.firstName en root.surnamefirst_name en last_name
root.emailprimary_email
work.titlejob_title
work.departmentdepartment_idsThrough a table per department
work.siteIdlocation_id, time_zone en languageTime zone and language per site
Leidinggevende (Reports to)reporting_manager_id en initiator_id
work.startDateOnboardingverzoek (cf_date_of_joining)
Beëindiging met redenOffboardingverzoek (cf_separation_type)

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.