Identity and access management
HiBob to OneLogin integration: OneLogin users from Bob, with the HiBob integration or custom
With an integration between HiBob and OneLogin, every new employee in Bob becomes a OneLogin user with job title, department, company and manager, and that user can no longer sign in once they have left in Bob. HiBob offers its own OneLogin provisioning integration that syncs on the start date by default; KoppelHet comes in when you want to derive roles from the job, use the employee ID as a fixed key, or handle departure differently per country.
What the integration does
Organisations that use Bob as their HR system and OneLogin as identity provider have often switched on the HiBob integration and still assign roles by hand in OneLogin afterwards. A new colleague only gets apps when IT gets round to it, and a departure in another country happens at a different moment than in the Netherlands.
- Bob gets a service user for KoppelHet with read rights on personal, work and lifecycle data.
- In OneLogin the administrator creates an API credential with the Manage Users right.
- Together with you we record which roles belong to which job, site and employment type.
- For a new employee KoppelHet creates the OneLogin user with roles, and asks OneLogin to run the mappings straight away.
- On departure KoppelHet sets the user to suspended at the moment agreed for that country.
What to watch for with HiBob and OneLogin
- HiBob's OneLogin integration syncs an employee on the start date by default. IT then has no time to prepare laptop and access. KoppelHet creates the user when they are created in Bob, but keeps them suspended until the start date, so roles and apps are ready without anyone being able to sign in yet.
- In the HiBob integration you choose how the status follows, with the Bob status, always active or always suspended. With the Bob status an inactive employee becomes a deactivated OneLogin user. KoppelHet sets the status per departure reason and per country, and keeps temporary leave separate.
- OneLogin expects the manager as a OneLogin user ID, not as a Bob ID or email address. KoppelHet looks up the manager through external_id and fills manager_user_id. If employee and manager start at the same time, KoppelHet creates the manager first.
- Employees who were already in Bob before the HiBob integration was switched on only go to OneLogin when a mapped field changes or HiBob starts a sync of everyone. At go-live KoppelHet compares all employees with OneLogin and puts the Bob ID in external_id for existing users.
- A user created in OneLogin through the API gets no invitation email. KoppelHet sets the work email on the user and lets the first sign-in follow what you set up in OneLogin, for example with a separate invitation from IT.
- Bob works with sites in several countries and time zones, and only sends a departure at midnight after the effective date in the site's time zone. KoppelHet uses the site to decide a separate role and a separate moment of suspension per country.
- Custom fields in OneLogin must exist first; an unknown field makes the creation of the whole user fail. A custom field in Bob, such as a cost centre, is only passed on by KoppelHet once the OneLogin administrator has created the field.
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 we use mappings in OneLogin instead of roles from KoppelHet?
Yes. KoppelHet then only sets the fields, and your mappings assign the roles. KoppelHet asks OneLogin to run those mappings directly on creation.
Is a leaver deleted from OneLogin?
No, the user is suspended. Deleting after the retention period remains IT's choice.
Does the integration read pay data in Bob?
No. KoppelHet's service user has no rights on pay.
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 OneLogin is set up in Bob under the provisioning integrations. According to HiBob, sync starts on the start date by default, triggered by a created, joined or updated employee; the status follows the Bob status or is fixed to active or suspended. HiBob can start a sync of all employees.
- KoppelHet reads HiBob through signed employee events (employee.created, employee.updated, employee.joined, employee.left, employee.temporaryLeave) and the People API (people search with showInactive).
- To OneLogin through API v2 with a credential with Manage Users: POST /api/2/users with username, email, firstname, lastname, title, department, company, external_id, manager_user_id, role_ids and custom_attributes, with mappings=sync. Username unique per subdomain; status 1 is active, 2 is suspended; no invitation email through the API.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in HiBob | Field in OneLogin | Notes |
|---|---|---|
root.id | external_id | |
root.firstName | firstname | |
root.surname | lastname | |
Naamgevingsregel | username en email | |
work.title | title | |
work.department | department | |
Bedrijf of entiteit | company | |
Leidinggevende | manager_user_id | |
Functie, site en soort dienstverband | role_ids | According to an agreed table |
Startdatum en vertrek | status (1 actief, 2 geschorst) |
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