If your organization runs multiple Qase workspaces, say, one per product line, one for platform, one for a contracted team, you've been managing user access to each workspace independently.

That means duplicate provisioning, inconsistent role assignments, and offboarding that requires touching every workspace individually.

Multiworkspace SSO & SCIM feature consolidates identity management at the organization level: one IdP configuration, one set of group mappings, and workspace access derived from those groups at login time.

Qase uses a single SAML configuration per organization, not per workspace. This configuration is set from the Workspace --> SSO Settings, so if you have multiple workspaces, choose one where you’ll manage and maintain it.

Your SAML Sign-in URL, Identity Provider Issuer, and x509 certificate must also be configured here before you proceed.

For multiworkspace setups, the key addition is the SAML attribute for group mapping, this is the attribute in your IdP’s SAML assertion that contains group membership information.

If you don’t specify an attribute, Qase will attempt to auto-detect it from commonly used names:

If your IdP uses a non-standard attribute name, you should set it here explicitly.

Once set, Qase will stop checking default values and will only use the attribute you provided.

The attribute value can be an array or a delimited string (comma, semicolon, or whitespace-separated). Qase handles both.

Now go to Global user management to create IdP groups and map them to workspaces.

Each group has a name (display label), an identifier (the value your IdP actually sends in the SAML assertion), and one or more target workspaces. One workspace can also be targeted by multiple groups.

Only workspace owners can manage organization level group mappings, and the organization must contain at least two workspaces for the feature to activate.

The SSO configuration includes a default role and a read-only new members checkbox. These apply organization-wide when new members are provisioned into a workspace.

There is no per-workspace role override at the SSO layer, if you need different roles per workspace, assign them after provisioning.

If the setting to add new users as read only is enabled and a workspace has no available read-only seats, provisioning will fail for that workspace.

The user will still be provisioned into other workspaces where seats are available.

When a user logs in via SSO, Qase checks which workspaces they should have access to and adds them if needed. If the user is already part of a workspace, their existing access remains unchanged. If not, they are added with a default role.

After that, Qase decides which workspace to open. If the user has accessed one of these workspaces before, they’ll be taken there.

Otherwise, they’ll land in the first available workspace automatically.

When a user is removed from a group, Qase checks if they still have access through any other group. If they do, their workspace access remains. If not, their access to that workspace is removed. This helps prevent users from losing access accidentally when groups overlap.

Deleting a user via SCIM at the organization level deactivates them across all workspaces and removes all group memberships.