SCIM Provisioning for Users and Groups
SCIM synchronizes Organization membership from your identity provider. SSO handles sign-in; SCIM handles provisioning and deactivation. Configure and test them separately.
Owner, Admin, and Identity Admin can configure directory provisioning in Governance → Access → Identity when enterprise identity features are available.
Connect the directory
- Open Directory provisioning and copy the displayed SCIM base URL.
- Create the bearer token. Copy it immediately into the identity provider's provisioning configuration; it is shown only once.
- Choose the default provisioned role offered by the screen, Member or Viewer.
- Configure the identity provider to use the displayed URL and bearer authentication, then test its connection.
- Assign a small pilot group before enabling broader synchronization.
Use the SCIM token, not an ordinary platform API key or a user's password. Keep it in the provider's credential store and out of chat, screenshots, and ticket attachments.
The service supports Organization users and groups. Check the SCIM contract for supported attributes, filters, pagination, update forms, and provider compatibility before configuring custom mappings.
Map groups deliberately
After the provider sends its groups, use the mapping controls to assign a permitted Organization role and, optionally, a Team. A provider's group name alone does not grant administrative access. Only administrator-configured mappings grant the supported role or Team access.
Team membership is distinct from the Organization role. Verify the pilot user's actual workspace visibility after synchronization. Do not assume SSO's first login or a directory group with a familiar name automatically joins a Team.
Verify the full lifecycle
Test creation, an ordinary profile update, group membership changes, and deactivation. Confirm that the member appears in People & roles, receives only the intended Team access, and loses Organization access when deactivated.
SCIM deactivation affects Organization membership; it is not a request to erase the person's global account or delete historical agent work. Review connected credentials, machine identities, pending approvals, and agent responsibilities during offboarding.
The directory controls reactivation. While a managed person is inactive or deleted, SSO, invitations, and manual administrator actions cannot restore their Organization access. Reactivate the person in the identity provider; an invitation alone cannot resolve scim_reactivation_required. This also applies to people initially provisioned as inactive.
Deactivation keeps the directory resource available for reactivation. A SCIM DELETE removes it from directory queries and group memberships; reprovisioning creates a new directory ID and requires the provider to send group memberships again. The person's underlying platform account remains intact.
Username and work-email changes stay within this Organization. They preserve the platform account and identities in other Organizations. The current directory username or primary work email can be used for this Organization's SSO, provided its domain is allowed. Login-address changes require fresh Organization authentication. If a new address conflicts with another account, resolve the identity-provider mapping before retrying; the service does not merge accounts.
Seat availability, existing identities, protected memberships, and unsupported attributes can prevent an update. Inspect the provider's provisioning error and the current Organization state before retrying. Do not work around a conflict by creating a second account for the same person.
Organization suspension
An inactive Organization suspends every SCIM endpoint, including directory reads, discovery and OPTIONS. Requests receive the same generic 401 SCIM authentication error and Bearer challenge as an invalid token. Suspension preserves the token, configuration, directory resources and access mappings. Explicitly reactivating the Organization resumes an otherwise-valid token; it does not enable a disabled configuration, undo revocation or rotation, or reactivate an individually inactive directory user.
Provisioning mutations recheck Organization activity under the directory lock. A mutation that obtains the lock before deactivation may commit before deactivation completes; one admitted afterward is refused. Reads already admitted may finish. The application does not queue or replay refused requests: resume or reconcile provisioning through the identity provider after reactivation. Provider retry and connection-repair behavior varies; a 401 may require an administrator to resume provisioning even when the retained token remains valid.
Rotate or revoke the token
Rotation replaces the current token. Save the new value in the identity provider promptly, then run its connection test and a pilot synchronization. The old token stops authenticating; there is no overlap period to rely on.
Revocation stops future SCIM requests. It does not undo existing memberships or disable SSO. If your goal is offboarding, deactivate the intended members as well. If the new token was lost before saving, rotate again and replace it in the provider.