HaHR to ITSM
HiBob to HaloITSM integration: users per Bob site and tickets for joiners and leavers
With an integration between HiBob and HaloITSM, every colleague from Bob is a user in Halo, on the site that belongs to their Bob site, and the service desk gets an onboarding ticket well before the start date and an offboarding ticket before the last working day. After departure KoppelHet sets the user to inactive in Halo, so their tickets and devices can still be found.
What the integration does
Organisations that record HR in HiBob and handle IT requests in HaloITSM often only see new colleagues in Halo after the Entra ID import, which only follows once IT has created the account. Without an integration the service desk hears about a new colleague through a separate message, and about a departure at a site abroad sometimes only when the laptop has been idle for weeks.
- HR adds the new colleague in Bob, often weeks before the start date.
- KoppelHet fetches the current details and creates the user in Halo, on the site of the Bob site, with job and department.
- Within the agreed lead time before the start, an onboarding ticket is created in the new colleague's name, with start date and manager in the text.
- When someone gets a different department or job in Bob, KoppelHet updates the user and a ticket for access and workplace follows.
- One week before the planned last working day the offboarding ticket arrives. After that day the user becomes inactive.
What to watch for with HiBob and HaloITSM
- On a change HiBob only sends the employee's ID and which fields changed, not the new values. KoppelHet then requests the employee and only writes to Halo what really differs, so Halo's limit on calls per five minutes does not fill up with empty updates.
- Anyone in Bob who has not started yet is left out of HiBob API search results by default. KoppelHet requests those colleagues on purpose, so the Halo user and the onboarding ticket exist before the laptop has to be ordered.
- HiBob only reports a departure at midnight after the last working day. For the offboarding ticket KoppelHet therefore uses the planned leave date from the daily check; setting the user inactive in Halo only follows HiBob's notification.
- Each site in Bob has its own time zone, and so does a site in Halo. KoppelHet maps them one to one, so a ticket for a colleague at a site abroad follows that country's working day and not head office's.
- Creating a user in Halo without an existing Halo ID always produces a new user. When a former colleague returns and gets a new record in Bob, KoppelHet first searches the inactive users by work email, so their earlier tickets stay with the same Halo user.
- If Halo's Entra ID import runs alongside this integration, it fills in the work email later on the same user. KoppelHet records per field whether Bob or Entra ID leads, so no second Halo user is created for the same colleague.
- KoppelHet only processes notifications that provably come from HiBob. A forged notification therefore cannot cause an offboarding ticket or an inactive user in Halo.
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 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.
Frequently asked questions
Can the onboarding tasks stay in Bob?
Yes. HR tasks such as the welcome email stay in Bob onboarding. The Halo ticket only covers what IT has to arrange, such as laptop, accounts and access.
Do colleagues from every country go into Halo?
Only those from the Bob sites your service desk serves. A site Halo does not know is skipped by the integration and reported in the platform.
Do existing employees get a ticket at go-live?
No. The first run only puts the users right in Halo. Tickets only follow from new colleagues, changes and departures.
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 signed webhooks (employee events v2, including employee.created, employee.updated and employee.left) containing only the employeeId and, on an update, the IDs of changed fields, and through the HiBob API people search with showInactive. Fields include root.id, root.firstName, root.surname, root.email, work.title, work.department, work.siteId and work.startDate.
- Halo is written through the Halo REST API with an API application (client credentials). POST /Users with site_id, department, title and customfields; without an id POST creates a new user, so first GET /Users with search and includeinactive. inactive on departure; DELETE /Users/{id} also removes related objects and is not used. POST /Tickets with tickettype_id, user_id, site_id, summary and details. Rate limit 700 calls per 300 seconds per tenant, above that HTTP 429.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in HiBob | Field in HaloITSM | Notes |
|---|---|---|
root.id | Eigen veld Bob-id (customfields) | Key to find the Halo user again |
root.firstName en root.surname | firstname en surname | |
root.email | emailaddress | The work email; empty until IT has created the account |
work.title | title | |
work.department | department | |
work.siteId | site_id | Through a table from Bob site to Halo site |
work.startDate en leidinggevende | Onboardingticket: tickettype_id, user_id, site_id, summary, details | |
Gewijzigde afdeling, functie of site | Ticket van het tickettype voor wijzigingen | |
Geplande vertrekdatum | Offboardingticket, daarna inactive = true |
Related
Ashby → HiBob
Ashby to HiBob integration: a hire from Ashby straight in as an employee in Bob
Bullhorn → HiBob
Bullhorn to HiBob integration: an approved placement as a new employee in Bob
Carerix → HiBob
Carerix to HiBob integration: successful match becomes a new employee in Bob
Greenhouse → HiBob
Greenhouse to HiBob integration: from a hire in Greenhouse to a new employee in Bob