<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D5WR00002GbvRr0AJOkta Classic EngineOkta Integration NetworkAnswered2026-10-15T15:31:03.000Z2026-10-13T07:26:44.000Z2026-10-15T15:31:03.000Z

SmitaBB.12515 (Customer) asked a question.

Issue - Provisioning Import Users failing with unique constraint error

Hi Team,

 

There is custom SCIM app.

While importing the users manually, there is a unique constraint 'null' error.

Managed to populate all required details in the app response profile.

 

However, it is failing always.

 

Any help/suggestion would help. Thank you in advance!

 

Below is the excerpt from the Import Logs.

 

 "displayMessage": "Import process complete",

 "eventType": "system.import.complete",

 "outcome": {

  "result": "FAILURE",

  "reason": "import job failed"

 },

 "published": "2026-10-13T06:50:32.244Z",

 "securityContext": {

  "asNumber": null,

  "asOrg": null,

  "isp": null,

  "domain": null,

  "isProxy": null

 },

 "severity": "ERROR",

 "debugContext": {

  "debugData": {

   "jobId": "ij118nk9m3sVbdvGS698",

   "appname": "trial-9114921_scimbsso_1",

   "message": "SQLIntegrityConstraintViolationException: Column 'ancestor' cannot be null"

 


  • Paul S. (Okta, Inc.)

    Hello @SmitaBB.12515 (Customer)​ Thank you for posting on our Community page!

     

    You are asking why the manual user import for your custom SCIM app fails every time with a unique constraint error on a null value, even after the required profile details were populated.

     

    The import usually fails when the unique identifier or userName value returned by your SCIM endpoint is null or duplicated for one or more users, so the fix is to verify those values in both the endpoint response and the app configuration.

     

    Root Cause: Okta's import job requires a non-null, unique value in the field set as the unique identifier for users, and the username must map to a populated value. A null or duplicate value in any imported record causes the import job to fail.

     

    Solution: Follow these steps:

    1. Navigate to Applications → your custom SCIM app → Provisioning → Integration, and confirm that "Unique identifier field for users" points to a field your SCIM endpoint returns for every user (commonly userName or email, not a field that is empty for some accounts).
    2. Verify your SCIM endpoint's GET /Users response. Check that every user record includes a non-empty userName and that the unique identifier field has a distinct value for each user.
    3. Review the attribute mappings in Directory → Profile Editor → your app → Mappings → App-to-Okta tab. Confirm that the userName mapping has a source attribute that is populated and not mapped to null.
    4. Remove any duplicate or incomplete records from the endpoint data set, then rerun the import from the app's Import tab.
    5. Check Reports → Import Monitoring for the updated job result.
    6. If the import still fails with the same message after these checks, open a case with Okta Support and provide the import job ID (ij118nk9m3sVbdvGS698) and the app instance ID. The error refers to an internal database column, so Okta Support needs to review the job on the back end.

     

     

    Thank you for reaching out to our Community and have a great day!

    --

    Help others in the community by liking or hitting Select as Best if this response helped you.

    Expand Post
  • SmitaBB.12515 (Customer)

    Hi @Paul S. (Okta, Inc.)​ ,

    Thank you so much for your response.

     

    Yes, I had already ensured to populate the userName and also email in the app responses.

     

    Further, when I disable the Groups endpoint and retain only users, it works well.

    However, with Groups I see this issue.

    Could you please help.

     

     

    Providing you more details below.

     

     

    Get ALL /Users response:

    ---------------------------------------- Users - Start ----------------------------------------

    {

     "schemas" : [

      "urn:ietf:params:scim:api:messages:2.0:ListResponse"

     ],

     "totalResults" : 1,

     "startIndex" : 1,

     "itemsPerPage" : 3,

     "Resources" : [

      {

       "id" : "Sample_123",

       "userName" : "09_1_oct_new_test@sample.com",

       "displayName" : "oct_new",

       "active" : true,

       "emails" : [

        {

         "value" : "09_1_oct_new_test@sample.com",

         "type" : "work",

         "primary" : true,

         "display" : "09_1_oct_new_test@sample.com"

        }

       ],

       "groups" : [ ],

       "name" : {

        "familyName" : "test",

        "givenName" : "oct_new"

       },

       "schemas" : [

        "urn:ietf:params:scim:schemas:core:2.0:User"

       ],

       "externalId" : "okta234"

      },

      {

       "id" : "sample_234",

       "userName" : "02_09_oct_new_test@sample.com",

       "displayName" : "Oct",

       "active" : true,

       "emails" : [

        {

         "value" : "02_09_oct_new_test@sample.com",

         "type" : "work",

         "primary" : true,

         "display" : "02_09_oct_new_test@sample.com"

        }

       ],

       "groups" : [ ],

       "name" : {

        "familyName" : "New2",

        "givenName" : "Oct"

       },

       "schemas" : [

        "urn:ietf:params:scim:schemas:core:2.0:User"

       ],

       "externalId" : "okta234"

      },

      {

       "id" : "sample_234",

       "userName" : "03_09_oct_new_test@sample.com",

       "displayName" : "Oct",

       "active" : true,

       "emails" : [

        {

         "value" : "03_09_oct_new_test@sample.com",

         "type" : "work",

         "primary" : true,

         "display" : "03_09_oct_new_test@sample.com"

        }

       ],

       "groups" : [ ],

       "name" : {

        "familyName" : "3new",

        "givenName" : "Oct"

       },

       "schemas" : [

        "urn:ietf:params:scim:schemas:core:2.0:User"

       ],

       "externalId" : "okta_123"

      }

     ]

    }

     

     

    Note: id and externalId fields are not the actual values, I have given sample values here

     

    ---------------------------------------- Users - End ----------------------------------------

     

     

    Get ALL /Groups response:

     

    ---------------------------------------- Groups Start ----------------------------------------

     

    {

     "schemas" : [

      "urn:ietf:params:scim:api:messages:2.0:ListResponse"

     ],

     "totalResults" : 32,

     "startIndex" : 1,

     "itemsPerPage" : 32,

     "Resources" : [

      {

       "id" : "f720d065-4ec4-4b0d-8648-7445614177f8",

       "meta" : {

        "created" : "20261013 065031.362",

        "lastModified" : "20261013 065031.362",

        "resourceType" : "Group",

        "location" : "en-US"

       },

       "displayName" : "Boomi - Event Notifications - Administrator",

       "schemas" : [

        "urn:ietf:params:scim:schemas:core:2.0:Group"

       ]

      }

     ]

    }

    --------------------------------------- Groups - End ----------------------------------------

     

     

    Expand Post
    • Paul S. (Okta, Inc.)

      Hello @SmitaBB.12515 (Customer)​ I would recommend to open a case with Support for addinional investigation on this matter.

  • SmitaBB.12515 (Customer)

    HI Paul,

     

    I did try creating a case. I am not able to create a case with my account.

     

    Any assistance would be helpful

    • Paul S. (Okta, Inc.)

      Hello @SmitaBB.12515 (Customer)​ 

       

      The Groups import fails because the SCIM responses you shared contain duplicate identifiers, a Groups list that does not match its reported totals, and group records without the membership data Okta needs to build group relationships.

      Root Cause: Four issues appear in the responses:

      1. Duplicate user identifiers. Two users share the id "sample_234" and the externalId "okta234" is used by two users. Okta matches users and group members by id, so duplicate values can break the membership link and violate the unique constraint.
      2. Incomplete Groups list. The response reports "totalResults": 32 and "itemsPerPage": 32, but returns only one resource. Okta cannot reliably read group membership when the list and pagination data disagree.
      3. Group records without members. The group returned has no "members" array. Okta needs membership data to resolve group relationships, and a missing parent or membership reference can produce a null value in an internal column.
      4. Non-standard timestamps. The meta values "20261013 065031.362" are not ISO 8601. Use a format such as "2026-10-13T06:50:31Z".

      Solution: Follow these steps:

      1. Assign a unique, stable "id" to every user in the Users endpoint. Verify that no two users share an id or externalId.
      2. Return all groups from GET /Groups, not only one. Correct the totalResults, startIndex, and itemsPerPage values so they match the number of resources returned, and support pagination with startIndex and count.
      3. Include a "members" array in each group representation (GET /Groups and GET /Groups/{id}). Each member entry must have a "value" that matches an existing user "id". For groups without members, return an empty array rather than omitting the field.
      4. Format all meta.created and meta.lastModified values as ISO 8601 timestamps.
      5. Confirm that the Okta SCIM 2.0 template is used for the app, not the Application Integration Wizard (AIW) template. The AIW template sends group updates as PUT and the Okta SCIM 2.0 template uses PATCH, and Okta Community guidance recommends the SCIM 2.0 template for group operations. If your endpoint supports only PATCH, confirm that the group push and group update operations use the operations supported by your endpoint.
      6. Navigate to Applications → your app → Push Groups, create the group push with a small test group that has one assigned user, then check the Import Monitoring report under Reports → Import Monitoring.
      7. If the error persists after the endpoint responses validate, open a case with Okta Support and provide the job ID (ij118nk9m3sVbdvGS698) and the Groups endpoint responses, since the "ancestor" column is an internal database field.

       

      Expand Post

Loading
Issue - Provisioning Import Users failing with unique constraint error