SCIM (System for Cross-domain Identity Management) is a standard for managing user identities, capable of provisioning users and maintaining their status and group memberships over time. This is particularly useful for enterprise customers, allowing you to manage users in one central location, propagate statuses and group memberships to various applications.
Setting Up SCIM
To set up SCIM, users need two key pieces of information:
SCIM Base URL
Auth Token (for Bearer authentication)
Both of these can be found on the Account/Security Settings page.
User Attribute Support / Requirements
Supported standard SCIM attributes:
userName (required) - maps to user email and must be the user’s email address (this is fairly standard and configurable in identity providers)
displayName - maps to user name
user.givenName - used to build user name
user.familyName - used to build user name
For setting a user’s name, we give precedence to displayName. Otherwise, we will fall back to user.givenName and user.familyName. If none of these are set, we default to the first part of the user’s email address.
Group Attribute Support
Supported standard SCIM attributes:
displayName - maps to a team name
members - maps to team memberships
License Provisioning
Convention: We provision editor licenses based on a group with the name “ProductPlan Editors” (case insensitive)
If a new team membership comes in through SCIM for the group ProductPlan Editors and the user is not already an editor...
We will give the user an editor license.
If there are no editor licenses left on the account, no changes will be made.
If a team membership is being removed through SCIM for the group ProductPlan Editors and the user is an editor, we remove their editor license.
User De-provisioning
User de-provisioning happens when a user’s Active status changes to false (this is part of the SCIM specification).
When a user is de-provisioned, the platform sets them as Removed in our system, but the user is kept on the account.
This allows the deactivated user’s data to remain on the account. Account Admins can do things like transfer roadmaps.
Other side effects: Team memberships and permissions are removed.
A removed user is unable to login.
A removed user shows up in the Inactive tab on the user management page.
Notes
Q: If there’s a group within a group in Okta / EntraID, how does that translate over to us?
EntraID only syncs group memberships for direct members of a group. Okta does not allow groups within groups. However, both have the concept of “dynamic” groups. (i.e. you can assign group memberships based on user attributes like department, etc.). Dynamic groups sync over properly.
EntraID cycles/batches their provisioning (every 40 minutes). But, you can force provisioning to happen on-demand (examples in walkthrough videos).
This functionality is available for Enterprise level customers.