SSO and SCIM explained: Why you need both and how to set them up

When an employee joins, who creates their accounts in every business application? When they leave, who makes sure those accounts are switched off?

SSO (single sign-on) lets people authenticate through one trusted identity provider. SCIM (System for Cross-domain Identity Management) automatically manages their accounts in supported applications. Together, they make onboarding more consistent and reduce the risk of forgotten access. But they solve different problems, and neither replaces a sensible permissions policy.

What is SSO?

SSO lets employees use an identity provider (IdP), such as Microsoft Entra ID or Okta, to sign in to connected applications. Instead of each application checking a separate password, it relies on the IdP to verify the person.

Enterprise SSO commonly uses SAML or OpenID Connect (OIDC). These are different technical standards for exchanging authentication information. Your IdP can also enforce multifactor authentication (MFA), so a stolen password alone isn't enough to sign in.

SSO controls authentication. It doesn't necessarily create a user account in the application, assign the right project permissions or remove an account when someone leaves.

What is SCIM provisioning?

SCIM is a standardised way to exchange user information between an identity system and an application. When the application supports it, SCIM provisioning can create accounts, update names or email addresses, synchronise supported groups and deactivate accounts as access changes.

Think of SSO as checking someone's identity at the door. SCIM handles whether their account exists and remains active. Group-to-role mapping and access to specific resources still depend on what each application supports.

SSO vs SCIM: the difference at a glance

You can use SSO without SCIM, and SCIM is technically independent of SSO. For a growing organisation using many SaaS tools, using both usually reduces manual account administration.

Why businesses use SSO and SCIM together

Imagine a new project coordinator joining a team that uses ClickUp. IT adds them to the appropriate Entra ID or Okta application assignment. SCIM creates their ClickUp account. When they open ClickUp, SSO verifies their identity and applies the IdP's MFA requirements. An administrator still needs to check their ClickUp role and access to relevant work.

Six months later, they move departments. Supported SCIM mappings may update their details or Team membership, but access to individual Spaces and Lists must be reviewed separately. When they leave, the IdP blocks new SSO authentication and SCIM can deactivate their ClickUp Workspace access after synchronisation.

Employee access workflow

Joining: IT assignment → SCIM: ClickUp account created → SSO + MFA: identity verified → Workspace permissions checked

Leaving: IdP account disabled → new SSO login blocked → SCIM: ClickUp user deactivated → sessions and other credentials checked

This is where identity management connects to enterprise work management. Teams need access that follows real responsibilities, not a growing collection of manual exceptions. Your enterprise systems integration plan should account for how people gain and lose access, too.

How to set up SSO and SCIM: six practical steps

1. Check your subscriptions and integrations. Confirm that your application supports the chosen SSO method, SCIM provisioning and any group features you need. For ClickUp, Microsoft, Okta and custom SAML SSO require Enterprise; Google SSO is available on Business and above. A Workspace owner or admin enables SSO. See ClickUp's SSO requirements.

2. Decide who gets access. Define the source of employee identities, which users or groups are assigned to the application, and who approves administrator or guest privileges. Follow least-privilege principles rather than granting broad access by default.

3. Configure and test SSO. Add the application in Entra ID or Okta. For SAML, match the application's Entity ID and Assertion Consumer Service (ACS) URL with the IdP configuration. Supply the IdP's sign-in URL and signing certificate where requested. Test a real account before enforcing SSO for everyone.

4. Plan MFA and recovery access. Apply MFA through the IdP and establish an approved emergency administrator sign-in procedure. Keep any SSO exceptions tightly controlled and audited.

5. Enable SCIM. Copy the application's SCIM endpoint and token into the IdP's provisioning settings. Test the connection, check username/email matching, map supported attributes and roles, then assign a small pilot group. SCIM tokens are credentials: store them securely.

6. Test the entire lifecycle. Create a test user, change their details and group, then deactivate them. Check the actual application state, permissions and provisioning logs. A successful connection test alone doesn't prove offboarding works.

How to configure ClickUp SCIM with Microsoft Entra ID

Use a custom, non-gallery SAML application. The standard ClickUp Productivity Platform gallery application does not support SCIM provisioning. ClickUp's official Entra ID configuration guide documents the following route:

1. Create a new non-gallery enterprise application in Entra ID. In ClickUp, go to Workspace Settings → Security & Permissions → SSO → SAML.

2. Copy ClickUp's SP Entity ID into Entra's Identifier (Entity ID) field, and its ACS URL into Reply URL. Return Entra's Login URL and public signing certificate to ClickUp. Save metadata and complete the test sign-in.

3. In Entra, open the custom application's Provisioning tab and select Automatic. Enter ClickUp's SCIM Base URL as Tenant URL and its SCIM API Token as Secret Token. Select Test Connection and save.

4. Review user and group mappings, assign pilot users, and use Provision on demand before starting broader automatic provisioning.

Watch the limits: Entra groups create new ClickUp Teams, not links to existing Teams. Nested groups aren't supported, and conflicting application-role assignments can fail. Creating a Team doesn't give it access to Spaces, Folders or Lists; those permissions must be set separately. Without explicit role mapping, provisioned users default to members.

Provisioning isn't immediate. ClickUp's guide describes automatic Entra cycles running every 30 minutes by default; allow for processing and check logs before troubleshooting a missing user.

How to configure ClickUp SCIM with Okta

First enable Okta SSO in the ClickUp Enterprise Workspace. ClickUp then displays the SCIM Base URL and API Token.

In Okta → Applications → Applications → ClickUp → Provisioning, enable provisioning features and open Configure API Integration. Enter the ClickUp credentials, select Test API Credentials, then save. Under To App, choose the provisioning actions, assign test users and map the ClickUp Role attribute. An unset role defaults to member.

Okta can push new users, profile updates, groups as ClickUp Teams, deactivations and reactivations. Enable the relevant group-import feature if synchronising groups. Deactivating a user removes their access to that ClickUp Workspace while retaining their information as inactive. Follow the ClickUp Okta SCIM guide for role-specific settings.

Common setup mistakes and how to avoid them

SSO login fails: Recheck the SAML Entity ID, ACS URL, certificate and application assignment. SCIM connection tests don't validate SSO.

Duplicate or missing users: Compare usernames, email addresses, matching attributes and provisioning scope before retrying.

Unexpected Teams or permissions: Review group mappings and ClickUp role assignments. SCIM-created Teams still need access to relevant work shared explicitly.

Updates stall: Check provisioning logs and token validity. ClickUp documents expired tokens and rate limits as possible Okta errors; Entra provisioning runs in cycles rather than instantly. Microsoft's SCIM provisioning overview explains the model.

A former employee still has access: Verify downstream deactivation and check existing sessions, other Workspace memberships, alternative sign-in routes and API tokens. SSO blocking future logins isn't a complete offboarding audit.

Frequently asked questions

Do you need SCIM if you already have SSO?

Not always. Small teams may manage accounts manually. SCIM becomes more valuable when frequent hires, role changes or departures make manual provisioning difficult to track.

Is SCIM the same as SAML?

No. SAML carries authentication information for SSO; SCIM handles identity provisioning and account updates. One doesn't replace the other.

Can SSO create user accounts automatically?

Sometimes. Applications with just-in-time (JIT) provisioning can create an account when someone first signs in. That isn't the same as continuous SCIM-based lifecycle management.

Does SCIM instantly remove an employee's access?

Not necessarily. Provisioning depends on synchronisation, successful processing and the application's deactivation behaviour. Always confirm the result rather than assuming the IdP change has already propagated.
Make access management and integrations part of your ClickUp setup

Secure sign-in is only one part of a well-designed ClickUp workspace. Teams also need clear roles, defined tool ownership and reliable integrations between systems. In one SaaS migration we managed, ClickUp handled product, marketing and project management, while engineering continued using Jira. We connected both platforms through Make to synchronise status updates. Getting the status mapping right required several rounds of manual adjustments, but the integration has continued running since go-live. At Sharpflow Consulting, we consider these practical requirements during ClickUp onboarding and workspace design so teams can work confidently across connected tools.