Identity and access management
HiBob to Okta integration: Okta users from Bob, with the HiBob integration or custom
With an integration between HiBob and Okta, every new employee in Bob becomes an Okta user with job title, department, site and manager, and that user is deactivated after departure. HiBob offers its own Okta provisioning integration that sends employees to Okta on the start date or on creation, with free field mapping; KoppelHet comes in when you want your own rules for garden leave, contractors, multiple countries or a service desk.
What the integration does
Organisations that use HiBob and Okta and have switched on HiBob's Okta integration often still handle exceptions by hand in Okta. Think of different rules per country for garden leave or contractors, or a laptop IT wants ready before the first working day.
- HR creates a new employee in Bob; they show there as not yet started.
- KoppelHet stages the user in Okta with login and work email, and creates a workplace request in the service desk.
- The work email goes back to Bob, replacing the private address HR entered on creation.
- On the start date the user becomes active; groups for site, department and employment type grant the apps.
- On departure, deactivation follows the arrangement for that situation, such as the last day in the office or the end of the contract.
What to watch for with HiBob and Okta
- The HiBob integration puts an employee into Okta on the start date by default; you can change that to the moment of creation. KoppelHet creates the user on creation but keeps it staged until the start date, so IT can prepare and the colleague can only sign in on day one.
- According to HiBob the integration deactivates the Okta user on termination or on the last day in the office, whichever comes first. With garden leave that is the last day in the office. If in the Netherlands you want someone on garden leave to still email HR, or to block immediately on summary dismissal, KoppelHet records that per departure reason.
- The HiBob integration signs in to Okta with an API token. Such a token carries the rights of the Okta administrator who created it and expires after thirty days without use. KoppelHet uses an Okta app with OAuth and rights on users and groups only.
- Bob asks for an email address for a new employee right away, and HR often enters the private address. KoppelHet determines the Okta address with your naming rule and writes that work email back to Bob.
- If the integration may not read a field in Bob, HiBob leaves it out without an error. KoppelHet checks that all expected fields are present, so a missing department does not end up as an empty department in Okta and groups do not change unexpectedly.
- The employment type from Bob, such as permanent, temporary or freelance, goes to Okta. Group rules in Okta can then give contractors different apps than employees.
- Sites in Bob are in different countries. If each country has its own groups or email domain, KoppelHet derives them from the site, so a move to another country produces the right groups and domain.
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
Do we have to switch off the HiBob integration?
Not necessarily. If both run, we record per attribute in Okta which source leads, so they do not overwrite each other. If KoppelHet replaces the integration, we only switch it off after a parallel test period.
What about audit logging, GDPR and our integration platform?
Every action of the integration is in the audit logging of the KoppelHet platform, and the security and audit logging can go to your SIEM as JSON. You are the controller and KoppelHet is the processor, under a data processing agreement. The integration runs on KoppelHet's own platform, next to an existing integration platform.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- The HiBob integration with Okta is set up in Bob under Settings, Integrations, Provisioning, with the Okta domain and an Okta API token; HiBob mentions the choice between the Okta API and Okta SCIM. Field mapping is free, including custom fields. Okta API tokens inherit the administrator's rights and are valid for thirty days after creation or last use.
- KoppelHet reads HiBob through signed webhooks (including employee.created, employee.updated, employee.joined and employee.left) and the People API (people search with showInactive for employees who have not started). The work email goes back through the email endpoint (root.email).
- Okta is written through the Users API with an OAuth 2.0 service app (scopes okta.users.manage and okta.groups.manage): create without activation, activate and deactivate. If the HiBob integration runs alongside, we record per attribute which source leads.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in HiBob | Field in Okta | Notes |
|---|---|---|
root.id | employeeNumber | |
root.firstName | firstName | |
Achternaam | lastName | |
Naamgevingsregel | login en email | |
work.title | title | |
work.department | department | |
work.siteId | city en countryCode | Through a table per site |
Leidinggevende | managerId en manager | |
employment.type | userType | |
Startdatum en vertrekdatum | status (STAGED, ACTIVE, DEPROVISIONED) |
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