> ## Documentation Index > Fetch the complete documentation index at: https://help.standards.site/llms.txt > Use this file to discover all available pages before exploring further. # SCIM Provisioning Enterprise Standards supports SCIM 2.0, so your identity provider (IdP) can add, update, and remove workspace members and groups for you. When someone joins or leaves a team in your IdP, their access in Standards follows automatically. *** ## Getting started ### What SCIM does * **Provisions people:** People assigned to the Standards app in your IdP are added to your workspace as members. * **Syncs profile changes:** Name and email changes made in your IdP are applied to the member in Standards. * **Deprovisions people:** Deactivating or unassigning someone in your IdP removes their access to the workspace. * **Pushes groups:** Groups pushed from your IdP appear as groups on the **Access** page, with their membership kept in sync. Roles are not sent by SCIM. Give a provisioned group a workspace role in Standards and every member pushed into that group receives it. Learn more about [roles and groups](https://help.standards.site/workspace-members.md#groups). ### What is needed * A Standards workspace on an **Enterprise** plan * Owner or Admin permissions in the workspace * An identity provider that supports SCIM 2.0 with OAuth 2.0 bearer token authentication, such as Okta or Microsoft Entra ID > [!TIP] > > SCIM manages who is in your workspace. To have those people sign in with your IdP credentials, also set up [SAML SSO](https://help.standards.site/saml-sso.md). *** ## Standards setup **1. Create an API key for SCIM** From the dashboard sidebar, select **Settings**, then **API Keys**, and select `Generate key`. Name the key something recognizable, such as "Okta SCIM". Learn more about [API keys](https://help.standards.site/api.md). **2. Choose the SCIM scopes** Under the workspace scopes, select: * `scim.read` View members and groups * `scim.write` Manage members and groups No other scopes are needed. Select `Generate key`. **3. Store the Client ID and Client Secret** The `Client ID` and `Client Secret` are only shown once. Store them in a secure location before closing the dialog. **4. Find your workspace ID** Your workspace ID is in the URL when you're signed in to Standards. For example, in `https://app.standards.site/workspace/2e8cbaff83a`, the workspace ID is `2e8cbaff83a`. *** ## Identity provider setup Add a SCIM app (sometimes called an app integration or enterprise application) in your IdP and enter these values. The exact steps depend on your provider, so consult their documentation. | Setting | Value | | - | - | | SCIM base URL (Tenant URL) | `https://api.standards.site/beta/workspace/$WORKSPACE_ID/scim` | | Token endpoint | `https://api.standards.site/oauth/token/workspace/$WORKSPACE_ID` | | Grant type | `client_credentials` | | Client ID / Client Secret | The values from the API key you created | | Unique identifier field | `userName` (the person's email address) | Replace `$WORKSPACE_ID` with your workspace ID. Access tokens expire after 15 minutes, so your IdP needs to request a new token from the token endpoint as needed. See [API requests](https://help.standards.site/api-requests.md#service-login) for the full token request. ### Supported actions Enable these provisioning actions in your IdP: * Create users * Update user attributes * Deactivate users * Push groups and group membership Password sync is not supported, since people sign in to Standards with their own credentials or with [SAML SSO](https://help.standards.site/saml-sso.md). ### User attributes | SCIM attribute | Standards | Notes | | - | - | - | | `userName` | Email address | Required. Must be a valid email address. | | `name.givenName` | First name | Optional | | `name.familyName` | Last name | Optional | | `name.formatted` | Full name | Optional | | `displayName` | Display name | Optional | | `active` | Membership | `false` removes the person's access. `true` adds them back. | | `externalId` | IdP identifier | Optional. Stored and returned to your IdP. | | `emails` | Email address | Read only. Always restates `userName`. | ### Group attributes | SCIM attribute | Standards | Notes | | - | - | - | | `displayName` | Group name | Required. Must be unique in the workspace. | | `members` | Group members | Provisioned people only. Groups can't contain other groups. | | `externalId` | IdP identifier | Optional | *** ## How provisioned members behave ### On the Access page Members and groups created by your IdP show a label with the provider's name on the **Access** page. They are managed by your IdP, so they can't be deleted from Standards, and IdP groups can't be chosen when adding people to groups in Standards. Change names, email addresses, and group membership in your IdP and they'll sync to Standards. You can still give a provisioned group or person a workspace role, and allow them to view sign-in required guidelines. Learn more about [Allowed viewers](https://help.standards.site/access.md). ### Joining the workspace A provisioned person doesn't need a Standards account in advance. When they sign up with their provisioned email address, they're connected to the workspace with the access they've been given. ### Changes from your IdP * **Email changes:** Changing someone's `userName` updates their email address in Standards. They'll need to sign in with the new address to keep their access. * **Deactivation:** Setting `active` to `false` removes the person's access. Their group memberships are kept, so setting `active` back to `true` invites them back with the same groups. * **Deletion:** Deleting a user from the SCIM app removes them from the workspace entirely. * **Group changes:** Renaming a group or changing its members in your IdP updates the group in Standards. Deleting the group removes the access its members inherited from it. *** ## Technical reference The SCIM API follows [RFC 7643](https://www.rfc-editor.org/rfc/rfc7643) and [RFC 7644](https://www.rfc-editor.org/rfc/rfc7644). All endpoints are relative to the SCIM base URL. | Endpoint | Methods | | - | - | | `/Users` | `GET`, `POST` | | `/Users/{id}` | `GET`, `PUT`, `PATCH`, `DELETE` | | `/Groups` | `GET`, `POST` | | `/Groups/{id}` | `GET`, `PUT`, `PATCH`, `DELETE` | | `/ServiceProviderConfig` | `GET` | | `/Schemas`, `/Schemas/{id}` | `GET` | | `/ResourceTypes`, `/ResourceTypes/{id}` | `GET` | Read requests require the `scim.read` scope and changes require `scim.write`. * **Filtering:** `/Users` supports `userName eq "..."` and `/Groups` supports `displayName eq "..."`. Other filters return an `invalidFilter` error. * **Pagination:** Use `startIndex` and `count`. A page returns at most 200 resources. * **Attributes:** `attributes` and `excludedAttributes` are supported for top-level attributes. * **Not supported:** Bulk operations, sorting, ETags, and password changes. *** ## Troubleshooting > [accordion] Pushing a group fails with a uniqueness error > > A group, person, or domain in the workspace already uses that name. Rename or remove the existing group in Standards, or rename the group in your IdP. > [accordion] My IdP can't see members I added in Standards > > SCIM only lists members and groups created by your IdP. People and groups added manually on the **Access** page are not visible to your IdP. > [accordion] Requests fail with a 401 or 403 error > > A `401` means the access token is missing, invalid, or expired. Check that your IdP requests a new token from the token endpoint for your workspace. A `403` means the API key is missing the `scim.read` or `scim.write` scope. Edit the key in **Settings** → **API Keys** to add it. > [accordion] A provisioned person can't edit guidelines > > SCIM adds people without a workspace role. Give the person, or a group they belong to, a workspace role from the **Access** page. Learn more about [roles](https://help.standards.site/workspace-members.md#roles). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.