
Identity and access management
HiBob to JumpCloud integration: JumpCloud users from Bob, with the HiBob integration or custom
With an integration between HiBob and JumpCloud, every new employee in Bob becomes a JumpCloud user with job title, department, cost centre and company, and that user is suspended when they become inactive in Bob. HiBob itself manages a JumpCloud integration that creates users through SCIM; KoppelHet comes in when you want to handle the manager, more than ten custom fields, staged users or a departure per country.
What the integration does
Organisations with HiBob and JumpCloud usually start with the integration HiBob offers for JumpCloud. What remains afterwards is manual work in JumpCloud, such as filling in the manager, staging new colleagues without them being able to sign in yet, and exceptions for leave or departure.
- Bob gets a service user for KoppelHet with read rights on personal, work and lifecycle data, without salary.
- In JumpCloud the administrator creates an API key on a separate admin account.
- For a new employee KoppelHet stages the user in JumpCloud, with work email and the relation to the manager.
- On the start date the user is activated and gets apps and devices through groups.
- On departure KoppelHet suspends the user at the agreed moment; for temporary leave according to the agreement for that type of leave.
What to watch for with HiBob and JumpCloud
- The JumpCloud integration is managed and supported by HiBob, not by JumpCloud. When it fails, you start with HiBob's support. KoppelHet manages the integration itself, with logging per employee, so there is one party to talk to.
- The HiBob integration creates users only as active or suspended by default. Staged, the state JumpCloud recommends, takes a request to HiBob's support, as does the activation email on the move to active. KoppelHet creates the user as staged directly and activates them on the start date.
- The field table of the HiBob integration has no manager. JumpCloud does know the manager, as a relation to another user. KoppelHet looks up the JumpCloud user of the manager from Bob and sets that relation, so groups and approvals can follow the line.
- Through the HiBob integration at most ten custom fields go to JumpCloud, and a custom field that already exists in JumpCloud is not in the picklist. KoppelHet writes custom fields directly as attributes on the JumpCloud user, even if they already exist there.
- Employees who were already in Bob before the integration was switched on only reach JumpCloud when one of their mapped fields changes, or when HiBob starts a full sync. At go-live KoppelHet compares all employees with JumpCloud and links existing users to their Bob ID by work email.
- With deactivation on, the HiBob integration suspends a user as soon as someone becomes inactive or is deleted in Bob. Bob sends the departure notification at midnight after the effective date in the site's time zone. KoppelHet uses that time zone and can choose per country to suspend at the end of the last working day.
- Bob has leave where someone keeps access and leave where it stops, and only reports the second kind separately. KoppelHet suspends the JumpCloud user on that notification and activates them again when the leave ends, without creating them again.
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
Why not just the HiBob integration with JumpCloud?
Often it is enough if you do not need the manager in JumpCloud and suspending at inactive is always right. Choose custom work when groups must follow the line, or when leave and departure differ per country.
Is a leaver deleted from JumpCloud?
No, suspended. That keeps devices and history visible to IT; deleting after the retention period is a separate step.
Does the integration read pay data in Bob?
No. KoppelHet's service user may only read personal, work and lifecycle data.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- The HiBob integration is set up in Bob under Settings, Integrations, Provisioning, JumpCloud, with a JumpCloud API key from an administrator (role Manager, Administrator or Admin with Billing). Options for timing (on creation, on the start date or a number of days before), who is included, deactivation and at most ten custom fields. JumpCloud SSO Package or higher.
- 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 for employees who have not started).
- To JumpCloud through API v1 (/systemusers, header x-api-key): employeeIdentifier (unique per user), jobTitle, department, costCenter, company, employeeType, manager as a relation, attributes for custom fields and state STAGED, ACTIVATED or SUSPENDED.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in HiBob | Field in JumpCloud | Notes |
|---|---|---|
root.id | employeeIdentifier | |
root.firstName | firstname | |
root.surname | lastname | |
Naamgevingsregel | username en email | |
work.title | jobTitle | |
work.department | department | |
Kostenplaats | costCenter | |
Bedrijf | company | |
Leidinggevende | manager | JumpCloud ID of the manager |
Soort dienstverband | employeeType | |
Startdatum, verlof en vertrek | state (STAGED, ACTIVATED, SUSPENDED) |
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