HiBob User Management Guide

• Model type: hybrid
• Description: HiBob uses a hybrid model combining predefined system roles (Admin, Manager, Employee) with custom roles that admins can create. Permissions are scoped along two axes: people scope (which employees a role can see, e.g., by department, site, or reporting line) and data scope (which fields and modules are accessible). Field-level visibility can be configured per role.
• Custom roles: Yes
• Custom roles plan: All plans (module availability may affect what can be included in a custom role)
• Granularity: Field-level and module-level; admins can restrict visibility and editability of individual profile fields per role, and scope access to specific people groups.

1. Log in as Admin and navigate to the People tab.
2. Click the '+ New Employee' button (top-right of the People list).
3. Enter required fields: First Name, Last Name, Start Date, Site, and Department.
4. Assign a manager (optional at creation but typically required for org chart accuracy).
5. Set the employee's role/permissions if different from the default Employee role.
6. Send an invitation email to the new employee (optional; can be deferred).
7. Complete additional profile sections (compensation, employment details) as needed.

Required fields: First Name, Last Name, Start Date, Site, Department

Watch out for:

• The employee record is created immediately upon saving, even before the invitation email is sent; the employee counts as a seat from creation.
• Email address is required to send the invitation but may not be mandatory to create the record depending on account configuration.
• New employees added manually do not automatically sync to connected IdPs unless SCIM provisioning is configured.
• If onboarding workflows are configured, they trigger automatically based on start date and role; verify workflow rules before adding employees in bulk.

• Can delete users: No
• Delete/deactivate behavior: HiBob does not permanently delete employee records. Instead, employees are 'terminated' (offboarded), which moves them to an inactive/alumni state. Historical data, audit logs, and records are retained. This is consistent with HRIS compliance requirements for record retention.

1. Navigate to the employee's profile in the People tab.
2. Click the three-dot menu (⋮) or 'Actions' button on the employee profile.
3. Select 'Terminate Employee'.
4. Enter the termination date, reason for termination, and any required offboarding fields.
5. Confirm the termination; the employee is moved to the 'Inactive' or 'Alumni' section.
6. If SCIM is configured, the termination event can trigger automatic deprovisioning in the connected IdP.

Watch out for:

• Termination date determines when the employee loses system access; setting a future termination date means the employee retains access until that date.
• Offboarding workflows (task lists, document collection) must be configured in advance to trigger automatically on termination.
• Terminated employees remain visible to admins in the Alumni/Inactive view; they are not purged from the system.
• If the terminated employee was a manager, their direct reports may become unassigned in the org chart; reassignment must be done manually or before termination.
• SCIM deprovisioning is not automatic unless the IdP is configured to listen for HiBob termination events via SCIM.

• Where to check usage: Settings → Account Settings → Subscription or Billing (exact path may vary; contact HiBob account manager for seat count reporting)
• How to identify unused seats: HiBob does not natively surface a 'last login' report in a prominently documented location. Admins can use the Reports module to build custom reports filtering by employee status and login activity if the data field is available. Inactive employees (terminated) are automatically excluded from active seat counts.
• Billing notes: HiBob uses custom per-employee-per-month pricing negotiated at contract time. Implementation fees are typically 10–20% of annual software cost. Multi-year commitments may yield 30–35% discounts. Seat counts are based on active (non-terminated) employees. Module add-ons (e.g., payroll, performance, compensation) may affect total contract cost.

When an employee is added in HiBob manually, that record does not automatically propagate to your IdP or downstream tools unless SCIM is configured - meaning access can be granted in HiBob days before the rest of your stack catches up.

Terminations carry the same risk: a future-dated termination in HiBob leaves the employee fully active until that date, and without SCIM deprovisioning, offboarding depends entirely on someone remembering to act in every app individually.

HiBob also has no natively surfaced last-login or inactive-user report, so identifying employees who have never logged in requires building a custom report in the Reports module, if the login activity field is available on your account.

HR admins consistently flag the custom role configuration as the most error-prone part of HiBob setup.

The two-axis permission model (people scope plus data scope) is powerful but requires deliberate configuration - misconfiguring either axis can silently expose sensitive compensation data to roles that should not have it.

Offboarding workflows are a second recurring pain point: they require significant upfront configuration, and first-time admins frequently find the termination flow confusing. Manager-level access is tightly coupled to org chart accuracy, so any structural errors in the hierarchy directly affect what managers can see.

Bulk CSV imports are also cited as fragile, with error messages that do not reliably identify the problem row.

Common complaints:

• Users report that the permission model, while flexible, is complex to configure correctly-particularly scoping custom roles to the right people groups without inadvertently exposing sensitive data.
• Some HR admins note that there is no straightforward 'last login' or 'inactive user' report, making it difficult to identify employees who have never logged in or are no longer active system users.
• Reviewers on G2 and Capterra mention that offboarding workflows require significant upfront configuration and that the termination flow can be confusing for first-time admins.
• Community users note that bulk CSV imports require strict field formatting and that error messages during import are not always descriptive enough to quickly identify the problem row.
• Some users report that manager-level permission scoping is tightly coupled to the org chart, so any org chart inaccuracies directly affect what managers can and cannot see.

HiBob's native SCIM 2.0 support is available on all plans but requires SSO to be configured first - that prerequisite blocks provisioning automation for teams that have not yet rolled out SSO.

If SSO is in place, SCIM covers the core provisioning lifecycle for Okta and Microsoft Entra ID and ensures that every app downstream of your IdP stays in sync with HiBob employee state.

Custom HiBob fields are not exposed via SCIM, so any workflow that depends on custom field data requires the REST API in addition to SCIM. Teams without SSO, or those needing custom field sync, should plan for API-based provisioning or a third-party integration layer from the start.

Bottom line

HiBob gives HR and IT teams a genuinely flexible permission model, but that flexibility comes with configuration overhead that is easy to underestimate.

The absence of a built-in inactive-user report, the org-chart dependency for manager scoping, and the SSO prerequisite for SCIM all create gaps that surface as access risk if not addressed deliberately.

Teams that invest in SCIM setup and clean org chart hygiene upfront will get reliable lifecycle automation across every app in their stack; teams that skip those steps will find manual provisioning and offboarding errors accumulating faster than expected.