Identity and access management
HiBob to Ping Identity integration: employees from Bob as users in PingOne
With an integration between HiBob and Ping Identity, every new employee in Bob becomes a user in PingOne, in the population of their site or country and with job title, department and manager. After a departure or during leave without access the user can no longer sign in, and deletion only happens after the retention period.
What the integration does
Organisations that use HiBob for HR and PingOne for single sign-on and MFA often add new colleagues to PingOne by hand after HR sends a message. Leavers then keep access until someone disables the account, and moves to another site or department do not reach the groups in PingOne.
- In Bob the administrator creates a service user for KoppelHet with read rights on the required fields; PingOne gets a Worker app with the Identity Data Admin role.
- KoppelHet subscribes to Bob's employee notifications and fetches the current data on each notification.
- A new employee becomes a PingOne user in the population of their site, with sign-in blocked until the first working day.
- Department and site determine the groups; a transfer moves the user on the effective date.
- On departure KoppelHet blocks sign-in and only deletes the user after the agreed retention period.
What to watch for with HiBob and Ping Identity
- PingOne has a ready-made HR provisioner for Workday, but not for HiBob. Ping Identity is also not among HiBob's provisioning integrations. KoppelHet supplies the users to PingOne itself, through the APIs Ping describes for that purpose.
- HiBob only sends a notification about a departure or a new start at midnight after the effective date, in the site's time zone. A colleague in Singapore is therefore blocked hours earlier than one in Amsterdam. KoppelHet also puts that time zone on the PingOne user as timezone, so sign-in policies use local time.
- Bob has leave where someone stays active and leave where access stops. Only the second kind produces a notification. KoppelHet then blocks sign-in in PingOne, and allows it again when the leave ends, without deleting the user.
- A username in PingOne is unique in the environment, case-insensitive and at most 128 characters long. If PingID runs in the same environment, the name cannot change after creation. KoppelHet therefore builds the name from a fixed rule, not from a surname that HR later changes in Bob.
- Bob has sites in several countries, and PingOne puts each user in one population, which can only be changed through a separate request. KoppelHet maps each site to a population and moves the user with that separate request when they transfer to another country, so MFA devices and history remain.
- If the service user in Bob may not read a field, HiBob leaves it out of the response without an error. KoppelHet checks for every employee that department, site and manager are present, so a permission problem does not empty a whole group in PingOne.
- If an employee is deleted in Bob instead of being marked as having left, HiBob only passes on the email address. KoppelHet uses that address to find the PingOne user and blocks them, instead of waiting for the nightly comparison.
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 PingOne then create accounts in other applications?
Yes, with PingOne's own outbound provisioning. KoppelHet makes sure the data from Bob is right.
Does salary data go to PingOne?
No. The service user in Bob cannot read salary or bank details.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- HiBob through signed employee events (employee.created, employee.updated, employee.joined, employee.left, employee.temporaryLeave, employee.deleted with email address) and the People API (people search with showInactive for employees who have not started). A service user with read rights on root, work and lifecycle; no salary.
- PingOne with a Worker app with the Identity Data Admin role: users through /v1/environments/{envID}/users or the SCIM entry point (DirectMappedUsers for custom attributes), username unique and at most 128 characters, title and type at most 256 characters, timezone as an IANA name, population.id only changeable through the population sub-resource, groups through the Platform API and sign-in blocked through enabled.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in HiBob | Field in Ping Identity | Notes |
|---|---|---|
root.id | externalId | Fixed key, also after a name change |
Naamgevingsregel | username | At most 128 characters |
root.firstName en surname | name.given en name.family | |
Werkadres | email | |
work.title | title | |
work.department | Groep en eigen attribuut afdeling | |
work.reportsTo | Eigen attribuut leidinggevende | |
work.site | population.id en timezone | |
Soort dienstverband | type | |
Lifecycle-status | Blokkeren of toestaan van aanmelden |
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