Bullhorn User Management Guide

• Model type: role-based
• Description: Bullhorn uses a role-based permission model. Each user is assigned a User Role that defines which entities (candidates, jobs, placements, etc.) they can view, add, edit, or delete. Roles are configured by administrators and can be customized at a granular entity and field level. Data visibility can be further restricted by department and record ownership settings.
• Custom roles: Yes
• Custom roles plan: Not documented
• Granularity: Entity-level (candidate, contact, job, placement, etc.) with field-level visibility and edit controls per role. Ownership and department-based data partitioning available as an additional layer.

1. Log in as an Administrator.
2. Navigate to Menu > Admin > User Management.
3. Click 'Add New User' or the equivalent 'New' button.
4. Enter required user details: first name, last name, username, email address.
5. Assign a User Role from the available role list.
6. Set department assignment if applicable.
7. Set a temporary password or trigger an email invitation depending on configuration.
8. Save the new user record.

Required fields: First name, Last name, Username, Email address, User Role

Watch out for:

• Usernames must be unique across the Bullhorn instance and cannot be changed after creation.
• The user role must be configured before adding users; assigning an incorrect role may grant unintended data access.
• New users may not receive an activation email automatically depending on SSO or password configuration; administrators may need to manually communicate credentials.
• Adding users beyond contracted seat count may trigger billing changes; confirm seat limits with Bullhorn account manager before provisioning.

• Can delete users: No
• Delete/deactivate behavior: Bullhorn does not delete user accounts. Users are deactivated (marked as inactive), which prevents login but preserves all associated records, activity history, and ownership data. This is consistent with Bullhorn's audit trail and data integrity requirements.

1. Log in as an Administrator.
2. Navigate to Menu > Admin > User Management.
3. Search for and open the target user record.
4. Set the user's status to 'Inactive' or uncheck the 'Active' flag.
5. Save the record.

Watch out for:

• Deactivated users cannot log in but their username cannot be reused for a new user account.
• If the departing user owned active job orders or placements, ownership should be reassigned before deactivation to avoid workflow disruption.
• API integrations or automation rules referencing the deactivated user's credentials will fail after deactivation.

• Where to check usage: Menu > Admin > User Management - filter by Active status to view all active (billable) users.
• How to identify unused seats: Sort active users by Last Login date in User Management to identify accounts with no recent activity. Bullhorn does not provide a native 'unused seat' report; administrators must manually review last login timestamps.
• Billing notes: Bullhorn is sold on annual contracts with a fixed seat count. Adding users beyond the contracted number requires contacting the Bullhorn account manager. Deactivating users may not automatically reduce the billed seat count mid-contract; verify terms with Bullhorn directly.

Bullhorn is sold on annual contracts with a fixed seat count; adding users beyond that count requires contacting your account manager, and deactivating users mid-contract may not automatically reduce your billed seat count. Full user seats are reported in the $99–$315/user/month range depending on plan tier;

read-only seat pricing is not publicly listed and must be confirmed with Bullhorn directly. There is no native bulk-import path - every user must be created individually through the UI, and usernames cannot be changed after creation, which creates friction when employees change names or email addresses.

Community evidence is not specific enough to quote or summarize yet for this app.

Bullhorn's native SCIM 2.0 support is gated to Corporate/Enterprise plan tiers. If your contract sits below that tier, automated provisioning requires either the REST API or fully manual administration.

For teams managing every app in their stack through a centralized IdP, confirming SCIM availability and the tenant-specific SCIM endpoint with your Bullhorn account team is the right first step before committing to a provisioning architecture.

Bottom line

Bullhorn's user management is functional but deliberately manual by default - no bulk import, no unused-seat reporting, and no automatic record reassignment on deactivation.

Teams on Corporate or Enterprise plans can unlock SCIM 2.0 to reduce that overhead, but the SCIM endpoint is not self-service and must be provisioned by Bullhorn.

For organizations where recruiter headcount changes frequently, the combination of annual seat contracts and manual-only provisioning on lower tiers makes proactive seat auditing a recurring operational necessity.