Highspot User Management Guide

• Model type: role-based
• Description: Highspot uses a role-based model with a small set of built-in roles (Admin, User, Partner, Learning-Only). Permissions are further scoped by group membership and Spot-level access controls. Admins can configure which groups can access which Spots and what actions (view, download, pitch) are permitted within each Spot.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Role-level (Admin vs. User) combined with Spot-level and group-level access controls. Individual permission overrides are not available; access is managed through group assignments and Spot permissions.

1. Log in as an Admin and navigate to Settings → Users.
2. Click 'Invite Users' or 'Add User'.
3. Enter the user's email address.
4. Select the appropriate role (Admin or User) and seat type.
5. Assign the user to one or more Groups (optional at invite time; can be done later).
6. Click 'Send Invitation'. The user receives an email invite to set up their account.

Required fields: Email address, Role (Admin or User), Seat type / license type

Watch out for:

• Invitations expire; if a user does not accept within the expiry window, the admin must resend.
• Users are not automatically added to any Spot; group assignment or direct Spot permission must be configured separately.
• If SSO is enforced, users must authenticate via SSO on first login; password-based login may be disabled.
• Seat limits are contractually defined; inviting users beyond the contracted seat count may require account team approval.

• Can delete users: No
• Delete/deactivate behavior: Highspot does not permanently delete user accounts from the admin console. Admins can deactivate (disable) a user, which revokes login access and removes the user from active seat counts, but the user record and associated data are retained in the system.

1. Navigate to Settings → Users.
2. Locate the user by searching by name or email.
3. Click on the user's name or the action menu (ellipsis) next to their record.
4. Select 'Deactivate User' (or 'Disable User' depending on UI version).
5. Confirm the deactivation in the dialog prompt.

Watch out for:

• Deactivated users are not automatically removed from Groups; admins should manually remove them from group memberships to keep group-based permissions clean.
• If SCIM provisioning is active, deprovisioning the user in the IdP (Okta, Azure AD) will automatically deactivate the user in Highspot; manual deactivation is redundant but not harmful.
• Content owned by a deactivated user is not reassigned automatically; orphaned content may become difficult to manage without a documented offboarding process.
• Reactivating a previously deactivated user restores their account and prior group memberships; verify group assignments are still appropriate before reactivating.

• Where to check usage: Settings → Users (shows active vs. inactive users and seat assignments); detailed seat utilization reporting may require contacting the Highspot account team or accessing the Analytics dashboard.
• How to identify unused seats: Filter the Users list by 'Last Login' date to identify users who have not logged in recently. Highspot does not provide a native 'unused seat' automated report in the standard admin UI; admins must manually review last-login data.
• Billing notes: All pricing is custom-quoted; no self-serve plan changes. Seat count adjustments (up or down) require coordination with the Highspot account team. Mid-cycle seat additions are typically prorated. Hybrid licensing (mixing full, partner, and learning-only seats) can reduce total contract cost. Implementation, content migration, and premium support are typically billed separately.

All pricing is custom-quoted and seat count changes require coordination with the Highspot account team - there is no self-serve portal for adjustments. Mid-cycle additions are typically prorated, and hybrid licensing across Full, Partner, and Learning-Only seats can reduce total contract cost.

Hidden costs to budget for separately include implementation, content migration, and premium support - none of which are bundled into the per-seat price. SCIM provisioning is gated to the Enterprise plan and requires SSO to be active first, so teams on lower tiers carry the full manual provisioning burden.

Identifying unused seats requires manually filtering the Users list by Last Login date. There is no native inactive-user report or automated cleanup workflow in the standard admin UI, which means seat audits are a recurring manual task.

Admins on G2 and TrustRadius consistently flag that group and permission management becomes difficult at scale, particularly because there are no custom roles to create intermediate access tiers between Admin and standard User.

Every app access decision has to be routed through group assignments, which multiplies the configuration surface as headcount grows.

Two operational gaps come up repeatedly: no automated alert when seat limits are approaching, and no self-serve seat management - both of which slow down rapid headcount changes. Deactivated accounts are retained in the system rather than removed, leading to cluttered user lists over time.

CSV bulk-import errors are reported as poorly described, requiring trial-and-error to resolve. The absence of a dedicated inactive-user report means last-login audits must be run manually on a schedule admins define themselves.

Common complaints:

• Admins report that there is no automated notification when seat limits are approaching, requiring manual monitoring.
• Users note that deactivated accounts are not fully removed, leading to cluttered user lists over time.
• Reviewers on G2 and TrustRadius mention that group and permission management becomes complex at scale, with no custom role creation to simplify access tiers.
• Some admins report friction when onboarding large user cohorts because CSV import errors are not always clearly described, requiring trial-and-error to resolve formatting issues.
• The lack of a self-serve seat management portal means any seat count changes require going back to the Highspot account team, which slows down rapid headcount changes.
• Last-login visibility is available but a dedicated 'inactive user' report or automated cleanup workflow is absent from the standard admin UI.

Manual provisioning in Highspot is viable for small, stable teams but becomes a liability as headcount scales. The combination of no custom roles, no automated seat alerts, and no self-serve contract changes means admin overhead compounds with every new hire or departure.

If your organization already has Okta or Azure AD (Entra ID) in place and is on the Enterprise plan, SCIM provisioning eliminates the repetitive invite-and-group-assign cycle. The decision point is straightforward: teams without Enterprise or without an established IdP will manage users manually and should build explicit audit cadences into their IT workflows.

For teams with Partner or Learning-Only seat mixes, pay close attention to group assignments at invite time - mixing seat types in the same group is a documented source of permission confusion, and fixing it after the fact requires manual cleanup.

Bottom line

Highspot's manual user management is functional but unforgiving at scale: no custom roles, no automated seat alerts, no self-serve contract changes, and no native inactive-user report mean that every app access decision and every offboarding requires deliberate admin action.

Teams that invest in clean group structures and a documented last-login audit cadence will stay ahead of the sprawl; teams that don't will find deactivated accounts, orphaned content, and permission confusion accumulating faster than the admin UI makes them visible.