Box User Management Guide

• Model type: role-based
• Description: Box uses a role-based model with fixed system roles (Admin, Co-Admin, Managed User, External User) at the account level, and a separate folder/item-level collaboration permission model (Owner, Co-Owner, Editor, Viewer Uploader, Previewer Uploader, Viewer, Previewer, Uploader) applied per content item. Co-Admin permissions are configured from a predefined set of administrative permission categories rather than fully custom roles.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Account-level: 4 fixed roles (Admin, Co-Admin, Managed User, External User). Content-level: 8 collaboration roles per folder/file. Co-Admin permissions are toggled from ~10 predefined administrative permission categories.

1. Log in to Box as Admin or Co-Admin with user management permissions.
2. Navigate to Admin Console (https://app.box.com/master/users).
3. Click 'Users & Groups' in the left sidebar, then select 'Users'.
4. Click the '+ Add User' button in the top-right corner.
5. Enter the user's name and email address.
6. Optionally set storage quota, user role (Managed User or Admin/Co-Admin), and group memberships.
7. Click 'Add User' to send an activation email to the new user.

Required fields: Full name, Email address

Watch out for:

• The email address must be unique across all Box accounts globally, not just within the enterprise.
• If SSO is enforced, the user's email must match the IdP identity; mismatches prevent login.
• New users receive an activation email; if they already have a personal Box account with that email, they must convert or merge it before joining the enterprise.
• Storage quota defaults to the account-level default unless overridden per user.
• Co-Admin creation requires the creating Admin to explicitly assign permission categories after account creation.

• Can delete users: Yes
• Delete/deactivate behavior: Box supports both deactivation and permanent deletion. Deactivating a user suspends their access while preserving their account, content, and audit logs. Deleting a user permanently removes the account; content must be transferred or deleted before or during the deletion process. Deletion is irreversible.

1. Navigate to Admin Console > Users & Groups > Users.
2. Click on the user's name to open their profile.
3. Click the gear/settings icon or 'Edit User'.
4. Select 'Deactivate User' from the options.
5. Confirm the deactivation. The user is immediately logged out and cannot log back in.

Watch out for:

• Deactivated users still count against the license seat total; to reclaim the seat the account must be deleted.
• Content transfer must be initiated before or during deletion; there is no post-deletion recovery.
• If the user owns a folder that is the root of a collaboration, deleting without transferring will remove collaborator access to that folder.
• Box does not provide a native 'offboarding workflow'; admins must manually handle content transfer, group removal, and external collaboration cleanup.
• Deleted user accounts cannot be restored; Box Support cannot recover a deleted account.

• Where to check usage: Admin Console > Account & Billing > Account Info (shows total licensed seats vs. active users); also visible at Admin Console > Users & Groups > Users (user count displayed)
• How to identify unused seats: Admin Console > Reports > User Activity report can be run to identify users with no login activity within a specified date range. Admins can also export the full user list to CSV and filter by 'Last Login' date.
• Billing notes: Seats are billed annually by default. Adding users mid-cycle results in prorated charges for the remainder of the billing period. Deactivated users still consume a seat; only deleted users free the seat. Enterprise discounts of 15–56% are available via direct sales negotiation. Box does not auto-downgrade seats; unused seats must be manually removed at renewal.

Every app has a deactivation-versus-deletion gap, but Box makes it operationally expensive: deactivated users continue consuming a licensed seat until a separate deletion step is completed.

Deletion is irreversible and requires content to be transferred first - Box provides no native offboarding workflow, so admins must manually handle content transfer, group removal, and external collaboration cleanup for every departing user. External collaborator auditing has no bulk tooling, making large-scale access reviews a manual, export-and-filter exercise against the Users CSV.

The most consistent friction reported by Box admins centers on provisioning architecture and offboarding gaps.

Box's user provisioning API does not conform to the SCIM 2.0 standard - the userName field is not required and schema deviations exist - which breaks assumptions made by generic identity automation tooling.

Admins relying on Okta or Microsoft Entra ID for provisioning are locked into those IdP-specific connectors rather than a portable SCIM endpoint.

The deactivated-user-still-billed behavior is a recurring source of unexpected license costs, and the absence of a structured offboarding flow means every app offboarding is a multi-step manual process with no guardrails against content loss.

Common complaints:

• Not SCIM-compliant despite being enterprise file storage; Box's user provisioning API does not follow the SCIM 2.0 standard (e.g., userName field not required, schema deviations).
• Confusing provisioning story: Box has IdP-based provisioning via Okta and Microsoft Entra ID but this is not native SCIM; it relies on IdP-specific connectors.
• Must use IdP-specific integrations (Okta app, Entra ID enterprise app) rather than a generic SCIM endpoint, creating vendor lock-in for provisioning.
• Deactivated users continue to consume licensed seats, requiring a separate deletion step to reclaim licenses - a common source of unexpected billing.
• No built-in offboarding workflow; content transfer, group removal, and collaboration cleanup must be done manually or scripted via API.
• External collaborator management is difficult at scale; there is no bulk tool to audit or remove all external collaborators across the enterprise.
• Co-Admin permission model is not granular enough for some organizations; permissions are toggled from a fixed category list rather than being fully customizable.
• Users with existing personal Box accounts on the same email must go through a conversion process before joining an enterprise, causing friction during onboarding.

Box manual management is viable for teams under ~50 users with a stable roster and an existing Okta or Entra ID deployment handling provisioning. Beyond that scale, the absence of native SCIM compliance, no offboarding workflow, and the seat-billing behavior on deactivated accounts create compounding operational overhead.

Teams that need to enforce consistent access reviews across every app in their stack, or that use an IdP other than Okta or Entra ID, will find Box's provisioning story particularly limiting. The two-layer permission model (account roles plus per-item collaboration roles) also means access audits require checking both layers independently.

Bottom line

Box delivers robust enterprise content management but its identity lifecycle story has meaningful gaps: provisioning depends on IdP-specific connectors rather than standard SCIM, there is no native offboarding workflow, and deactivated users continue to consume licensed seats until manually deleted.

For organizations managing access across every app in their environment, these gaps translate directly into audit risk and unrecovered license spend.

Teams with Okta or Entra ID already in place will get the most out of Box's provisioning capabilities; everyone else should plan for scripted or manual workarounds to cover the gaps.