Summary and recommendation
Benchling user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Benchling uses a two-tier permission model: organization-level roles (Admin, Member) govern platform access and administrative capabilities, while project-level roles (Admin, Editor, Viewer) control what users can do inside each project.
Permissions are additive within projects but do not cascade automatically across the organization.
Every app in a life-sciences stack that touches Benchling data inherits whatever access the underlying Benchling role permits, so role hygiene matters beyond Benchling itself.
Native SCIM provisioning is available, but only on the Enterprise plan.
Teams on Startup or Professional plans must manage users entirely through the admin console at Organization Settings > Members.
Quick facts
| Admin console path | Organization Settings > Members (accessed via the organization name or avatar in the left sidebar) |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Organization Admin | Full administrative control: invite/remove members, assign roles, manage organization settings, configure SSO/SCIM, manage billing and integrations. | All paid plans | At least one Organization Admin must remain active; admins cannot remove themselves if they are the sole admin. | ||
| Member | Can access projects and notebooks they are granted access to; can create and edit records within permitted projects. | Cannot manage organization settings, invite users, or configure integrations. | All plans | Access to specific projects is controlled separately at the project level; being an org Member does not automatically grant access to all projects. | |
| Project Admin | Can manage membership and permissions within a specific project, including adding/removing project members and setting project-level roles. | Cannot manage organization-level settings or invite new users to the organization. | All plans | Project Admin is a project-scoped role, not an organization-wide role. | |
| Viewer / Read-only | Can view notebooks, entries, and data within projects they have been granted read access to. | Cannot create, edit, or delete records. |
Permission model
- Model type: hybrid
- Description: Benchling uses a two-tier permission model: organization-level roles (Admin, Member) control platform access and administrative capabilities, while project-level roles (Admin, Editor, Viewer) control access to specific projects and their contents. Permissions are additive within projects.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Organization-level and project-level role assignments; no field-level or record-level custom role builder documented in official help docs.
How to add users
- Navigate to Organization Settings > Members.
- Click 'Invite Members' or 'Add Members'.
- Enter the user's email address.
- Select the organization-level role (Admin or Member).
- Send the invitation; the user receives an email to accept and set up their account.
Required fields: Email address, Organization role (Admin or Member)
Watch out for:
- Invited users must accept the email invitation before they appear as active members.
- Users not yet in the system will receive an account-creation email; existing Benchling users will be added directly.
- Project access must be granted separately after the user joins the organization.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Unknown | Not documented |
| Domain whitelisting | Unknown | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: Benchling's official documentation describes deactivating (removing) users from the organization rather than permanently deleting accounts. Deactivated users lose access to the organization but their data and records are retained. No permanent account deletion workflow is documented in official help docs.
- Navigate to Organization Settings > Members.
- Locate the user in the member list.
- Click the options menu (three dots or similar) next to the user's name.
- Select 'Remove from Organization' or 'Deactivate'.
- Confirm the action.
| Data impact | Behavior |
|---|---|
| Owned records | Records, notebook entries, and data created by the deactivated user are retained and remain accessible to other organization members with appropriate permissions. |
| Shared content | Shared projects and collaborative content remain intact and accessible to remaining members. |
| Integrations | Not documented |
| License freed | Deactivating a user frees their seat, making it available for reassignment. |
Watch out for:
- If the deactivated user is the sole Organization Admin, another admin must be assigned before deactivation is possible.
- SCIM-provisioned users deactivated via the IdP will be automatically deactivated in Benchling on Enterprise plans.
- Deactivated users cannot log in but their historical contributions remain attributed to them in audit logs and records.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Academic seat | Full platform access for academic/non-commercial use | $0 |
| Startup seat | Full platform access under Startup plan | Included in $15,000/year plan (seat count subject to plan terms) |
| Professional seat | Full platform access under Professional plan | Included in $20,000+/year plan (seat count subject to plan terms) |
| Enterprise seat | Full platform access with SSO, SCIM, advanced permissions, and enterprise integrations | Custom pricing |
- Where to check usage: Organization Settings > Members (shows active member count); billing seat usage may be visible under Organization Settings > Billing depending on plan.
- How to identify unused seats: No officially documented automated inactive-user report; admins must manually review the Members list and cross-reference last-active dates if available.
- Billing notes: Pricing is plan-based rather than strictly per-seat for lower tiers; Enterprise pricing is custom and negotiated. Deactivating users frees seats per official documentation.
The cost of manual management
Adding a user requires navigating to Organization Settings > Members, clicking 'Invite Members', entering an email, and selecting a role. That step alone is straightforward. The compounding cost comes after: project access must be granted separately for every project the user needs, with no bulk assignment tool available.
Offboarding follows the same path - locate the user, open the options menu, select 'Remove from Organization', and confirm. Deactivated users lose login access immediately, but their records and audit-log entries are preserved. There is no documented permanent-deletion workflow.
Identifying unused seats adds a third manual layer. Benchling provides no built-in inactive-user report; admins must cross-reference the Members list against last-active dates manually.
At scale, this makes license hygiene a recurring time investment rather than a periodic check.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
SCIM on Enterprise eliminates the manual invite-and-confirm loop and keeps every app connected to your IdP in sync automatically. If your organization is already on Enterprise and running an IdP like Okta or Azure AD, SCIM is the clear path forward.
For Startup or Professional plans, the manual workflow is functional but does not scale cleanly past small teams. The project-by-project access model means onboarding a single user into a multi-project environment requires multiple discrete admin actions.
If seat cost and license visibility are priorities, factor in that there is no native tool to surface unused seats - that gap exists on every plan, including Enterprise.
Bottom line
Benchling's manual user management is straightforward for small teams but accumulates operational overhead quickly as project count and headcount grow. The absence of bulk project-access assignment and inactive-seat reporting are the two structural gaps that affect every app and workflow touching Benchling at scale.
SCIM provisioning resolves the provisioning and deprovisioning burden but is gated to Enterprise, leaving non-Enterprise customers with a fully manual process. Organizations evaluating Benchling for larger teams should weigh those gaps against their IT capacity before committing to a non-Enterprise plan.
Automate Benchling workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
