SCIM with YeshID

Last updated: May 1, 2026

Introduction

This article explains how to set up SCIM provisioning in YeshID, what to expect when moving an existing app from API-based provisioning to SCIM, and how to handle common migration scenarios. It also includes a migration checklist and FAQ to help teams validate app behavior before making bulk changes.

SCIM, or System for Cross-domain Identity Management, lets YeshID create, update, import, and remove application users through a standard provisioning protocol. SCIM is best for ongoing user lifecycle management after the connection is configured.

Before you begin

Make sure you have:

Admin access in YeshID.
Admin access in the target application.
The target application's SCIM base URL or endpoint.
The target application's required authentication method, such as a bearer token, OAuth2, Basic auth, or API key.
Any target-app prerequisites, such as SSO, domain verification, enterprise plan access, or SCIM enablement by the vendor.
A backup export of the application's current users before changing an existing integration.
- If the application already has users, export the account list from YeshID before switching the integration type. In the application account table, use the CSV export option to keep a record of current account names, owners, roles, and external IDs.

Set up SCIM in YeshID

In YeshID, go to Access > Applications.
Open the application you want to connect. If the application is not in YeshID yet, select Add Application first.
Select the application's Integration section, or choose Manage > Connect.
In Choose an integration type, select SCIM.
Enter the target application's authentication details.
Enter any required SCIM configuration fields. For a standard SCIM setup, the endpoint should usually be the SCIM base URL, such as https://example.com/scim/v2.
Select Save or Authenticate, depending on the authentication type.
Review the available Actions and enable only the actions you want YeshID to run.

App-specific behavior

SCIM standardizes many provisioning operations, but each application still controls how it handles existing users. YeshID can send standard SCIM requests, but the target application decides whether it can list, match, adopt, update, deactivate, or delete a user.

Before migrating a production app, document the app's behavior:

Question	Why it matters
Does SCIM list pre-existing users?	If not, users can disappear from the YeshID account list after switching to SCIM.
What field is used for matching?	Email mismatches are a common cause of duplicate accounts.
Does SCIM adopt existing accounts?	If not, users may need manual cleanup or a controlled recreate.
Are custom attributes required?	Missing vendor-specific fields can block user creation.
How does deprovisioning work?	Some apps deactivate users, while others delete, suspend, or remove workspace access.
How are groups returned?	Some apps return group names without members unless requested differently.

Use a pilot user first. A successful pilot should confirm both the YeshID account state and the target application's user state.

Migrating from API to SCIM

Moving an existing app from an API integration, manual management, or vendor-side management to SCIM is not always a one-click switch. The key question is whether the target application can connect existing accounts to SCIM records without creating duplicates or removing existing accounts.

Migration checklist

Before switching an existing app to SCIM, consider the following:

Does the SCIM /Users endpoint return all existing users, or only users created through SCIM?
Which field does the app use to match existing users, such as email, username, or employee ID?
What happens if the email or username in YeshID does not exactly match the app?
Does the app adopt existing users, create duplicates, require manual reconciliation, or return an error?
Are custom SCIM attributes required to create or adopt users?
Does deprovisioning deactivate users, delete users, suspend users, or remove them from a workspace?
If you plan to sync groups, does /Groups include members, or does the app require a separate group-member request?
Has the old API writer been disabled before enabling SCIM write actions?

Use one source of truth for write actions. If the old API integration and the new SCIM integration both create, update, or remove users at the same time, the application can drift or reject requests.

Scenario 1: Existing users remain visible

In the best case, the application returns existing users through SCIM or adopts them when YeshID sends a matching user by email. After you save SCIM and re-sync, the account list remains populated or repopulates with the same users.

This is most likely when:

Emails match exactly between YeshID and the application.
The application supports adopting existing accounts into SCIM management.
The SCIM /Users endpoint lists existing application users.
Required application fields already exist or can be supplied by YeshID.

Some applications document email-based adoption or account capture behavior. Examples include Notion, Figma, Dropbox, and Ramp when the user data matches. You should still test one user before bulk changes.

Scenario 2: Users disappear after switching to SCIM

If the account list becomes empty after moving from API to SCIM, it usually means the target application's SCIM /Users endpoint is only returning users that are already SCIM-managed.

The users may still exist in the target application. They are not necessarily deleted. YeshID simply cannot see them through the new SCIM import path.

To recover:

Confirm the users still exist in the target application's admin console.
Use your CSV export as a reference for the previous YeshID account list.
In YeshID, open the application and select Manage > Add User.
Start with one pilot user whose email exactly matches the target application.
Add that user through YeshID so SCIM can attempt to create or adopt the account.
Confirm the result in the target application.
If the pilot succeeds, add selected users or choose Add all active people.

Do not bulk add users until you understand whether the application adopts existing accounts or creates new ones.

Scenario 3: The application creates duplicate accounts

Some applications create a second account when SCIM cannot match the user to an existing profile. This can happen when:

The email in YeshID differs from the email in the application.
The application does not support account adoption.
The application requires a vendor-specific identifier or custom SCIM attribute.
The existing account was created through another provisioning path that SCIM cannot discover.

If duplicates appear, pause the migration. Clean up the test user first, then confirm the app's expected matching behavior before adding more users.

Apps that are known to be duplicate-risk or require extra validation include Miro and Ramp. Ramp can adopt existing users when profile data matches, but can create a second account when the email does not match.

Scenario 4: The application requires custom attributes

Some applications require non-standard SCIM attributes before they will create or adopt users. If those required fields are missing, the app may reject the request with a validation error.

Before bulk provisioning, check the application’s SCIM documentation for required fields beyond the standard profile fields. If the app requires custom attributes, contact YeshID Support before continuing.

Scenario 5: Groups import, but members are missing

Some applications return group names through /Groups but do not include group members in the same response. In YeshID, that can make groups appear with 0 members after switching to SCIM.

If this happens:

Confirm whether the target application's SCIM API includes group members in list responses.
Check whether the application requires a request such as /Groups?attributes=members.
Re-sync after confirming the expected provider behavior.
Contact YeshID Support if the provider requires an app-specific group import path.

This can happen with Zoom or other apps whose group list behavior differs from the standard YeshID SCIM mapping.

FAQ

Why did users disappear from YeshID after I switched to SCIM?

The most common reason is that the application's SCIM /Users endpoint only returns users that were created or adopted through SCIM. The users may still exist in the application, but YeshID cannot import them through SCIM until they become SCIM-managed or the provider exposes them through SCIM.

Did SCIM delete my users?

Not usually. An empty account list after switching to SCIM usually means the import returned no visible SCIM-managed users. Check the target application's admin console before assuming users were removed.

How do I re-add users after switching to SCIM?

Open the application in YeshID, select Manage > Add User, and add a pilot user first. If the result is correct, add selected users or choose Add all active people.

What if the app requires fields YeshID does not send by default?

Pause the rollout and check the app's SCIM documentation. Some apps require custom attributes for role, permission profile, department, location, or workspace assignment. YeshID Support can help confirm whether the field can be mapped or whether the app needs a custom setup.

Why do imported groups show zero members?

Some providers return group records without members in the default /Groups response. The provider may require an additional attribute request or a separate request per group. Re-sync after validating the provider's group behavior, or contact YeshID Support if the app needs a custom import path.

What should I do before a large migration?

Export the current YeshID account list, review the target app's SCIM documentation, disable the old write path, test one user, confirm whether the app adopts or duplicates the account, then migrate users in batches.