LangSmith · Cloud & Self-Hosted · Enterprise RBAC

LangSmith RBAC
& SCIM Provisioning Guide

Understand org and workspace roles, choose an isolation pattern, generate SCIM group names, and build custom roles — all in one place.

01

Access Hierarchy

LangSmith uses a four-level model: Organization → Workspace → Application → Resources. RBAC is enforced at the workspace level. Projects and runs inherit workspace permissions.

Organization
Your LangSmith Org
🛡 Org Admin
Workspace
Workspace 1
EditorViewer
support-ticket-routing
onboarding-assistant
live-chat-agent
Workspace
Workspace 2
EditorViewer
eval-benchmarks
user-research-synthesis
a-b-test-analysis
Workspace
Workspace 3
EditorViewer
code-review-agent
incident-response-bot
infra-automation
02

Workspace Isolation Patterns

Choose the organizational model that matches your team structure. This selection pre-fills the generator with the recommended workspace layout for each pattern.

PATTERN 01
Team-Centric
One workspace per team. Each team owns its own resources, runs, prompts, and datasets. The default model for most deployments.
Best for: Most teams. Promotes collaboration within a team, easy to manage with SCIM groups. Limited prod/dev isolation.
PATTERN 02
Collaborative
Advanced
Multiple teams share one workspace. Shared prompts and deployments, with ABAC (beta) restricting access to sensitive traces and datasets.
Best for: Cross-functional teams that share reusable components. Requires careful ABAC policy configuration.
PATTERN 03
Project-Isolated
Strict Isolation
Multiple workspaces per team, split by environment (Dev / Staging / Prod). Full isolation — resources cannot be shared across workspaces.
Best for: Regulated or enterprise environments requiring strict prod isolation. Adds operational complexity.
03

SCIM Group Name Generator

Select a team type to auto-fill workspace names for your chosen pattern, or type custom names. Names must exactly match the LangSmith display name — case-sensitive.

Team type:
scim-group-generator — team-centric
GROUP NAMING FORMAT
PREFIX
SEPARATOR
PREVIEWLS:Organization User:WorkspaceName:Admin
↳ workspace names
FIXED
LS:Organization Admins
always
1
↳ okta group strings
Include: Workspace Admin Org User: Editor Org User: Viewer Org Viewer
LS:Organization Admins
LS:Organization User:Workspace 1:Admin
LS:Organization User:Workspace 1:Editor
LS:Organization User:Workspace 1:Viewer
LS:Organization Viewer:Workspace 1:Viewer
04

User Access Preview

Add team members and assign them to Okta groups. The matrix shows exactly what each user can access — before you push to production.

add user
Name
Email
Okta Groups
access matrix
👤Add a user to see their access matrix
05

Role Reference

Permissions for each built-in role. Org Admin and Org Operator are org-wide; Workspace Admin, Editor, and Viewer are scoped per workspace.

🛡 Org Admin
Organization Admin
Org-level · all workspaces
  • Create, rename, and delete workspaces
  • Invite and remove organization members
  • Assign workspace roles to all users
  • Manage SCIM tokens and SSO settings
  • Access all workspaces by default
  • Manage billing, org-wide configuration, and custom roles
⚙ Org Operator
Organization Operator
Org-level · day-to-day ops
  • Create workspaces and invite Org Users and Org Viewers
  • Day-to-day operations and workspace management
  • Cannot manage Org Admins or configure SSO
  • Cannot create custom roles or manage billing
  • NOT automatically added to existing workspaces
  • Must be explicitly added to each workspace by an Org Admin
🔑 Workspace Admin
Workspace Admin
Workspace-scoped · full control
  • Full permissions for all workspace resources
  • Manage workspace members and assign roles
  • Create workspace-scoped service keys and API tokens
  • Configure workspace settings and automations
  • Cannot access org-level settings or billing
✏ Editor
Workspace Editor
Workspace-scoped
  • annotation-queues: create, read, update (no delete)
  • datasets: create, read, update, share (no delete)
  • deployments: create, read, update (no delete)
  • feedback: create, read, update, delete
  • projects: create, read, update (no delete)
  • prompts: create, read, update, share, tag (no delete)
  • runs: create, read, share (no delete)
  • Cannot invite members or change roles
👁 Viewer
Workspace Viewer
Workspace-scoped · read-only
  • Read-only access on all resource categories
  • View all runs, traces, and projects
  • Browse datasets and examples (read-only)
  • View prompts and deployment status
  • View annotation queues (no submissions)
  • Cannot create, edit, delete, share, tag, or invoke any resources
06

SCIM Naming Rules

The most common reasons SCIM group mapping silently fails.

Group Name Requirements
The LS: prefix is the recommended convention but is NOT required — the parser strips any prefix. LS:Organization User:Eng:Editor, organization user:Eng:Editor, and MyPrefix:Organization User:Eng:Editor all work.
Matching is case-insensitiveOrganization User and organization user are treated identically
Workspace name must exactly match the LangSmith display name — verify with GET /api/v1/workspaces
The separator (: by default) is configurable via FF_ALLOWED_SCIM_SEPARATORS. Supported: : - _ space &
Role values must be capitalized: Admin, Editor, or Viewer
Custom role names must exist in LangSmith first — create them in Settings > Members & Roles > Roles before configuring IdP groups
Use Organization Viewer for users who should not be able to create Personal Access Tokens
OIN App + SCIM Token
SCIM requires the OIN catalog app — custom apps have no Provisioning tab
Paste the bearer token as-is — no Bearer prefix in the API Token field
AuthHost = hostname only — no https://, no path, no trailing slash
Leave ApiUrlBase empty for self-hosted — cloud-only field
SCIM base URL: https://{AuthHost}}/scim/v2
07

Disable JIT Provisioning

When SCIM is active, JIT must be disabled. For self-hosted, use the Helm env var (chart ≥ 0.11.14).

values-cp.yaml
# Add to commonEnv in your values-cp.yaml
# Requires chart >= 0.11.14
# Do NOT use PATCH /api/v1/orgs/current/info — cloud-only

commonEnv:
  - name: SELF_HOSTED_JIT_PROVISIONING_ENABLED
    value: "false"
08

Custom Role Builder

Custom roles must be created in LangSmith before they can be used in SCIM groups. Define them here to preview their permission set and generate the correct SCIM group name format.

define role
Presets:
Annotation Queues
ReadCreateUpdateDelete
Datasets
ReadCreateUpdateDeleteShare
Deployments
ReadCreateUpdateDelete
Feedback
ReadCreateUpdateDelete
Tracing Projects
ReadCreateUpdateDelete
Runs
ReadCreateUpdateDeleteShare
Workspaces
ReadManageManage MembersManage Secrets
Prompts
ReadCreateUpdateDeleteShareTag
Automations / Rules
ReadCreateUpdateDelete
Charts / Dashboards
ReadCreateUpdateDelete
Alerts
ReadCreateUpdateDelete
MCP Servers
ReadCreateUpdateDeleteInvoke
Workspaces
Workspace 1
defined roles0 roles
🔧Define a custom role to see it here
09

Okta Setup — Assignments & Push Groups

This is the most common SCIM mistake. Two separate Okta tabs must both be configured. Pushing a group does not automatically add it to Assignments.

Both steps are required — missing either one breaks provisioning
Assignments tab only → user account gets created, but no workspace role assigned
Push Groups tab only → LangSmith gets the group/role info, but the user may have no account
Both configured → user account created + workspace role assigned ✓
STEP 1 — ASSIGNMENTS TAB
Controls who gets a LangSmith account provisioned
1. Okta → LangSmith App → Assignments
2. Click Assign → Assign to Groups
3. Find the SCIM group (e.g. LS:Organization User:Eng:Editor)
4. Click Assign → Done
Result: Okta calls SCIM /Users → user account created in LangSmith
STEP 2 — PUSH GROUPS TAB
Syncs group name + members so LangSmith assigns the workspace role
1. Okta → LangSmith App → Push Groups
2. Click Push Groups → By Name
3. Search for the group name
4. If "No match found" → click Create Group (normal for new groups)
5. Click Save
Result: Okta calls SCIM /Groups → workspace role assigned in LangSmith
PREREQUISITES — DO THESE IN LANGSMITH FIRST
Before creating Okta groups, both the workspace and role must already exist in LangSmith or the group push will fail silently.
Workspace exists
LangSmith → Settings → Workspaces
Name must match exactly — case-sensitive, must not contain the configured separator character
Custom role exists (if using one)
LangSmith → Settings → Roles
Role name in Okta group must match exactly — use Section 08 to build and name it
Workspace names cannot contain the separator character
The separator character is reserved for SCIM group name parsing. Workspace names must not contain it. LangSmith validates workspace names against ^[a-zA-Z0-9\-_ '@()]+$
If you rename a custom role in LangSmith, you must also rename the corresponding Okta group. There is no automatic sync.
One Okta group = one workspace + one role. A user needing access to two workspaces requires two separate Okta groups.
Organization Operator cannot be assigned via SCIM — must be manually assigned in LangSmith.