Migrating Pre-existing Users to SCIM Management Without Deletion – DataHub Customer Support Portal

Area: Deployment Issues

Sub-Area: SCIM / Identity Provisioning (Okta)

Issue

When SCIM provisioning is enabled in DataHub Cloud after users have already been created manually, those pre-existing users cannot be managed or placed into groups by the SCIM provider (e.g., Okta). This is because SCIM-provisioned users are tagged with a SCIM origin identifier and assigned a SCIM external ID that the identity provider references when pushing group memberships. Manually created users have neither, so Okta has no SCIM ID to reference and group membership pushes fail. Additionally, attempting to provision an already-existing user directly through Okta results in a 409 conflict error. The common assumption is that the only resolution is to bulk-delete all pre-existing users and re-provision them through SCIM, but a non-destructive backend migration path is available.

Error Messages

Automatic provisioning of user to app failed: Error while creating user Conflict. Errors reported by remote server: Resource with name already exists.
409 Conflict — Resource with name already exists

You Might Be Asking

Do I have to delete all my existing users and re-provision them through Okta to use SCIM group sync?
Why can't Okta push group memberships for users that already exist in DataHub?
Is there a way to adopt manually created DataHub users into SCIM management without disrupting their access?
What causes the "Resource already exists" 409 error when provisioning users via Okta SCIM?

Solution

DataHub Support can perform a backend migration that stamps existing users with SCIM origin metadata, effectively adopting them into SCIM management without deleting or disrupting any accounts. This is the preferred approach when a large number of users already exist in DataHub prior to SCIM being enabled.

Disable "Create Users" in Okta before assigning existing users to the SCIM application.
In your Okta SCIM application, navigate to Provisioning > To App and disable the Create Users setting (or pause provisioning entirely). This prevents Okta from attempting to create users that already exist, which would trigger 409 conflict errors.

Reference: Okta SCIM Provisioning — To App Settings
Assign your existing users to the Okta SCIM application.
With Create Users disabled, assign the pre-existing users to the SCIM application in Okta. Okta will not attempt to create them since provisioning is paused or Create Users is off.
Export the Okta user list and provide it to DataHub Support.
DataHub Support requires a mapping of each user's email address to their Okta user ID in order to stamp the correct SCIM external ID on each DataHub account. The most direct way to obtain this is via the Okta Users API:
```
GET /api/v1/users
```
This returns each user's id field alongside their profile data. Alternatively, export the User Accounts report from Reports > Entitlements and Access in the Okta Admin Console to a CSV file.
DataHub Support stamps SCIM origin metadata on existing users.
Using the email-to-Okta-ID mapping you provide, DataHub Support runs a backend script that writes the SCIM origin aspect to each existing user's record. The origin aspect stored on each user takes the following general form:
```
{
  "origin": {
    "value": "SCIM_client_<okta-user-id>"
  }
}
```
Once written, the origin aspect is visible at the following endpoint for verification:
```
https://<your-instance>.acryl.io/openapi/v3/entity/corpuser/urn:li:corpuser:<user-email>/origin
```
It is strongly recommended to test this on a single pilot user before running the full bulk update. Confirm the origin aspect is present and that Okta recognizes the user as SCIM-managed before proceeding to all accounts.
Run an Import in the Okta SCIM application to link existing users.
After the origin metadata has been stamped, trigger an Import in the Okta SCIM application. Okta will match existing DataHub accounts by email address and prompt you to confirm any that do not auto-match. This links Okta's internal user records to the now-SCIM-tagged DataHub accounts.

Reference: Okta SCIM Import and Matching Behavior
Re-enable normal provisioning settings in Okta and push group memberships.
Once the import is complete and users are linked, re-enable Create Users and any other provisioning settings that were paused. You can then push group memberships normally through Okta SCIM.
Handle case-sensitivity conflicts carefully.
If your DataHub instance contains duplicate user accounts that differ only by email casing (for example, urn:li:corpuser:User.Name@example.com and urn:li:corpuser:user.name@example.com), DataHub Support will apply the SCIM origin only to the lowercase variant, as this typically matches how Okta stores email addresses. Flag any accounts with mixed-case emails to Support so they can be handled individually to avoid mismatches.

Additional Notes

This migration approach is supported for DataHub Cloud (Managed DataHub) customers. The backend script requires DataHub Support access to your environment and cannot be self-served.
The scim.filter.scimCreatedOnly configuration flag (default: true) controls whether the SCIM API surfaces only SCIM-originated users. Setting this to false exposes all users via the SCIM API but does not resolve group membership sync, because Okta still has no SCIM external ID for manually created users. This flag is not a substitute for the origin metadata migration described above.
After re-provisioning, any new users who are provisioned directly by Okta SCIM for the first time will not be affected by this procedure — they will receive SCIM metadata automatically at creation time.
User-scoped metadata such as ownership assignments, saved views, and individually scoped policies are preserved throughout this process because no accounts are deleted. URNs remain unchanged.
If a conflict error persists for a specific user after the origin metadata has been stamped, verify that the email casing in DataHub exactly matches the email stored in Okta. A case mismatch will prevent Okta from recognizing the account as already existing, leading to another 409 conflict.
Schedule the migration and the Okta import step during a low-traffic window as a precaution, even though no user access is interrupted by the backend metadata update itself.

Issue

Error Messages

You Might Be Asking

Solution

Additional Notes

Related Documentation